Design Microservices 
Architecture with Patterns & 
Best Practices 


A step-by-step process for software system design and evolve from 
monolithic to microservices following the patterns & principles. 


Refactor architectures with different aspects of microservices pillars. 
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Architecture Design — Vertical Considerations 
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Way of Learning — The Course Flow 
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Monolithic Architecture 


Application 
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Modular Monolithic Architecture Patterns 


Architectures 


e Monolithic 
Architecture 


e Layered Architecture 
e Clean Architecture 


e Modular Monolithic 
Architecture 


Patterns&Principles 
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Design: Modular Monolithic Architecture 


Application 


Product Module Order Module 


Basket Module Payment Module 


Shipment Module Reporting Module 
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Microservices Architecture Patterns 


Architectures 


Microservices 
Architecture 


Patterns&Principles 
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Service Pattern 
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Persistence 
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Deployable 
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Microservices Communications 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
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HTTP Based RESTful 
API design 


GraphQL API design 
gRPC API Design 
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Backend microservices communicates with gRPC 
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Architectures Patterns&Principles 


Microservices Communications Patterns 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 
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scalability 
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Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices 
Communications 


HTTP Based RESTful API 
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gRPC API 

WebSocket API 

Gateway Routing Pattern 


Gateway Aggregation 
Pattern 


Gateway Offloading Pattern ° 


API Gateway Pattern 


Backends for Frontends 
Pattern-BFF 
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Microservices Async Communications Patterns 


Architectures Patterns&Principles Microservices Microservices Async FR 
, Microservices + The Database-per- Communications Communications . [ist products 
Architecture Service Pattern e HTTP Based RESTful API e Single-receiver e Filter products as per 
Message-based brand and categories 
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pha Communication (one-to-, Put products into the 
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Fan-Out Publish/Subscribe Messaging Pattern 
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Microservices Data Management Patterns 


Architectures Patterns&Principles Microservices Data 
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Independent 


Design: Microservices Architecture with CQRS, 
Event Sourcing, Eventual Consistency 
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Event-Driven Microservices Patterns 


Architectures Patterns&Principles 
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Microservices Deployment Patterns 


Architectures Patterns&Principles 


Microservices — 
Architecture 


Event-Driven 
Microservices 
Architecture 
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Service Pattern, Polygot 
Persistence, Decompose 
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Decomposition Pattern 
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Communications Patterns 


Microservices Data 
Management Patterns 


Event-Driven Architecture 


Microservices Distributed 
Caching 
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Deployments with 
Containers and 
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Deployment i 


Docker and Kubernetes , 
Architecture, Helm Charts 


Kubernetes Patterns; 
Sidecar Patterns, Service 


Mesh Pattern : 
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Pipelines i 


Deployment Strategies; ° 
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Microservices Resilience Patterns 


Architectures Patterns&Principles 


Microservices — 
Architecture 


Event-Driven 
Microservices 
Architecture 


The Database-per- 
Service Pattern, Polygot 
Persistence, Decompose 
services by scalability, 
The Scale Cube 
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Decomposition Pattern 
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Resilience Patterns; 7 
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Design: Serverless E-Commerce Microservices 


User 
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DEMO: Microservices Architecture Code Review 
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DEMO: Code review of Microservices Architecture NET Implementation 


httos://github.com/aspnetrun/run-aspnetcore-microservices 
httos://github1s.com/aspnetrun/run-aspnetcore-microservices 
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Course Target 


= Hands-on Design Activities 

= Iterate Design Architecture from On-Premises to Cloud Serverless 

= Evolves architecture Monolithic to Event-driven Microservices 

= Refactoring System Design for handling million of requests 

= Apply best practices with microservices design patterns and principles 


= Examine microservices patterns with all aspects like Communications, Data Management, Caching 
and Deployments 


= Prepare for Software Architecture Interviews 


= Prepare for System Design Architecture Interview exams 
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Architecture Design Journey 


Modular i : 
ag Microservices 
Monolithic 
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Macroservices to Nanoservices 


Modular 
ae Microservices 
Monolithic 


Monolithic Macroservices Microservices NanoServices 
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Which architecture approach we should choose ? 


= |t depends on your project 


= Use Mixed Architecture 


= Provide transitions between architectures Seen — 
Monolithic Microservices 


Monolithic Macroservices Microservices NanoServices 
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Architecture Design — Vertical Considerations 


eieiei Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 
Transaction Management 
Deployment 


Resilience 
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Way of Learning — The Course Flow 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem = Learn H Design H Adapt 


Problem: Increased Traffic, Handle More Request 


Problems 

e Our E-Commerce Business is growing 

e Need to handle greater amount of 
request per second 

e Provide acceptable latency for users 


WAR 


ge, 
Clean 
Axchitectufe, 
N J 
Solutions 
e Scalabilitiy 
. Vertical and Horizontal Scaling 
« Scale Up and Scale Out a ask 
20K 12K 
e Load Balancer 
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Problem: Break Down Application into Microservices 


Problems 

e Our E-Commerce Business is growing 
to compete the market 

, Required Independent Scale and Deployments 

e We should clearly identify microservices which parts 
could be independent scale and deploy 


| Shopping | 


Cart 


| Ordering l > 
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Solutions 
e Microservices Decomposition Patterns 
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Problem: Direct Client-to-Service Communication l = 


Problems 

e Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app. NoSQL 
Document 


Solutions NoSQL 
e Well-defined API Design Key-Value 
, Microservices Communication Patterns Gë 
Les Relational 
Relational 
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Problem: Inter-service communication makes i Uc HI 


heavy load on network traffic 


Problems 
e Network performance issues on inter-service 
communication 


r < 
Client Apps ! 
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Example Use Case rt 
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Solutions | gRPC 
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« Able to develop with different technologies with RPC } 
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Problem: Chat with Support Agent 


Problems 

- Business teams request to answer Customer queries 
by chatting with Support Agents 

e Real-time communication requirements 

e Sending/receiving messages in Chat window 


Example Use Case 
e E-commerce Online Agent help customer preferences 
as per product features on website 


Solutions 
e WebSocket APIs: Build real-time two-way 
communication applications 


Mary - Support Agent 


O 


Hi there @. If you have any questions 
feel free to set up a personal demo 
here. No strings attached. 
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Problem: Service-to-Service Communications E el HI 


Chain Queries 


ss ees a tS SS ec item me a Sé 
Problems . . . Service-to-Service Communications - 
e HTTP calls to multiple microservices Chain Queries 

e Chain Queries 


. Visit more than a few microservices ( Product 


e Increased latency 
2 |GetProduct 


Solutions 
e Aggregate query operations 
e Service Aggregator Pattern 


Client 
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Problem: Long Running Operations Can't Handle with 


Sync Communication 


Problems 

e HTTP calls to multiple microservices 

e Chain Queries 

e Visit more than a few microservices 

« Increased latency with Highly Coupling Services 

e Performance, scalability, and availability problems 


Best Practices 

e Minimize the communication between the internal 
microservices 

e make microservices communication in 
Asynchronous way as soon as possible. 


Solutions 


D D L 
- Asynchronous Message-Based Communications 


e Working with events 


Service-to-Service Communications - 
Chain Queries 


A D 
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Problem: Database Bottlenecks when Scaling, E ~ oe oe 
Different Data Requirements For Microservices 


Problems 

e Database are stateful service 
e Scaling stateful services are not easy EE 
e Vertical scaling has limits need to scale Horizonta! 
e Different Data Requirements For Microservices 


Microservices 
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Solutions kde 

, Scale Stateful Application Horizontal Scaling Cart ` Les 

e Service and Data Partitioning along Business 
Boundaries - Shards/Pods 


e Use NoSQL Database to gain partitioning y A 
e Identify Database Requirements following best |; Orderng 
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Question 


e How to Choose a Database for Microservices ? Wiehmetakaya: ae 


Problem: Cross-Service Queries and Write Commands E -~ H 
on Distributed Scaled Databases 


Considerations 

e Cross-services queries that retrieve data from 
several microservices ? 

e Separate read and write operations at scale ? 


Problems 

e Cross-Service Queries with Complex JOIN 
operations 

e Read and write operations at scale 

e Distributed Transaction Management 


Horizontal 


Data Partitioning 
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Solutions 

e Microservices Data Query Pattern and Best = ji________ 2 L 
Practices 

e Materialized View Pattern 

e CQRS Design Pattern 

« Event Sourcing Pattern 
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Problem: Manage Consistency Across Microservices gee Ho 
in Distributed Transactions 


Considerations 
e Distributed Transactions that required to visit several microservices ? 
e Consistency across multiple microservices VE ee e a a 


, , ' Client Apps , 
« Rollback transaction and run compensating steps ? ! 


No-SQL Read 
Database 


Shopping 
Problems EEN 
e Distributed Transaction Management 
e Rollback Transaction on Distributed Environment 


e Run Compensate Steps if one of service fail 


consume 
event 
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Relational RDBMS event 


Write Database 
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Solutions 
e Microservices Distributed Transaction Management 
Pattern and Best Practices 

e Saga Pattern for Distributed Transactions 

, Transactional Outbox Pattern 

e Compensating Transaction pattern 

e CDC - Change Data Capture 
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Problem: Handle Millions of Events 


Across Microservices 


Considerations 

e What if we have thousands of microservices that need to 
communicates with millions of events ? 

e If multiple subsystems must process the same events 

e Required Real-time processing with minimum latency. 

e Required complex event processing, like pattern matching 


“ses ece EE ee ee ee ee 
Client Apps , 


e Required process high volume and high velocity of data, E m 
f eg 1) 
i.e. lol apps. 9 Ee = 

2 SAGA = 

Problems 5 rai i 

e Decoupled communications for thousands of SC 

, ! ame ` publis 
microservices Gal ee event 


Order 
GD | Table 


e Real-time processing 
e Handle High volume events 
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Solutions 


e Event-driven architecture for microservices 
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Problem: Database operations are expensive, E a Ho 


low performance 


Considerations 

e Event-driven architecture comes with latency when 
publishing and subscribing events from the Event Hub. 

e Sync REST APIs communication make expensive calls to ryzza 
a database that reduce performance. 

e How can we make more faster that increase performance 
of communications in Microservices Architecture ? 


Microservices 
eg O) | "oar O gesend: 
Catal 
| Catalog JS Discount) 
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| 

() Event Hub / ; 
Event Backbone ' 

FAAS Stream ; 
Process 


Problems 

« Slowliness and Low Performance Communication 

e Latency when publishing and subscribing events 

e Rest APIs make Database calls that are expensive, low} 
performance 


Solutions 
e Distributed cache 
e Storing frequently accessed data in a distributed cache Mehmet Ozkaya 46 


Problem: Deploy Microservices at Anytime 
with Zero-downtime and flexible scale 


Problems 

e Business teams wants to add new features immediately 

e Innovate and experiment with new features 

e Deploy features immediately, not waiting for deployment dates. 


eee zm em zm 1 


e Flexible scale for market peek times Client Apps 


Considerations 

e Ensure continuity of service and minimize disruption 
e Allow for continuous delivery 

e Support high-traffic environments 


Solutions 

« Containers and Orchestrators 

e Deployment strategies; blue-green deployment, rolling 
deployment, and canary deployment. l-------- 

e Kubernetes Patterns; Sidecar Patterns, Service Mesh Pattern 

e DevOps and CI/CD Pipelines and Infrastructure as code (a 


mm em em em em em em em em em em em em em em em em em em em =~ zm 
N 


Distribute Microservices 


Cache 
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Choosing the Right Architecture for your Application 


E aw Chris Richardson 


+$: 


Just a reminder: picking the appropriate architecture 
for your application is a best practice. 


Monoliths are thefuture=— 


e Aaa 


“microservices are awestereetice 


at tee 
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Choosing the Right Architecture for your Application 


= The Majestik Monolithic 


GC) DHH @ 


"Monoliths are the future because the problem people 
are trying to solve with microservices doesn’t really line 
up with reality", | aspire to such savage language as 
that which flows from . PREACH 


BROTHER! @W @ 


Monoliths are the future 
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Every Architecture has Pros and Cons 


= Understand that every architecture has benefits and 
also drawbacks 


= Consider every architecture style as a SA Monolith Microservices 
= What is the Right Architecture for your Application? 
= It Depends.. 


= Monolithic Architecture and Microservice Architecture 
are architectural patterns. 


e ` 
+ ` 
e ` 
Q O 
` £ 
` £ 
A 


= No architecture pattern is better than other. 


= Design your system with focusing on context and 
non-functional requirements (-ilities) 


= WRONG: Microservices > Monolithic 
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Design for Business Requirements 


Every design decision must be justified by a business requirement. 

To avoid over-engineering the application architectures, keep to drive design for business requirement. 
Engineers are tend to be over-engineering with latest architecture styles, use latest tools. 

lt becomes an experimental application that use all latest fancy tools and architectures. 

We should clearly define functional and nonfunctional requirements. 


Define our limits, constraints and assumptions of the application and define business objectives 
clearly. 


Start and Grow Application with Metrics 
= How many Concurrent Users that our application handle ? 
= What is the target of expected Requests/second Latency ? 
= What level of application outage is acceptable? 


Business requirements drive these design considerations. 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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How to Follow the Course 


| strongly recommended that you should take this course from beginning to end. 


If you already familiar some architectures, jump into your target architectures and start to learn from 
that section. 


All sections are independent from each other and you can easily switch on sections with following 
different architectures. 


Every section starts with specific problem and solve this problem with learning new patterns- 
principles. 

If you are only interested in microservices architectures, skip first monolithic, layered, clean and modular 
monolithic architectures and jump to microservices architectures. 


You can skip some of Microservices vertical topics as per your experience and requirements. If you don't 
interest Decomposition, skip "Microservices Decomposition" and continue with "Microservices 
Communications" sections. 


Jump your problem and learn patterns & principles related that problem to design your final 
architecture. 


This is reference architecture course that you can take any part of the course according to your 
architectural requirements. Mehmet Ozkaya 
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How to Follow the Course - 2 


= Increase Speed 
If you feel comfortable on any particular topic, please increase the video speed 
to avoid losing motivation of the course. 


= Puta Review 
Please put a comment and review the course, when you feel ready at any time of 
the course, this will help me a lot for further courses. 


Playback Speed 
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Course Slides 


= Powerpoint Slides 
Find full PowerPoint slides the link in the resource of this video. 


Section 1: Introduction “A 
1/9] 39min 


1. Introduction 


Q 7min @ Resources v 


LJ 2. Preri Ø Microservices Architecture on... 


M nai: 
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Understand E-Commerce 
Domain 


Our First Problem: Sell Products Online. To Solve this problem, we 
should understand our domain which is E-Commerce. 


Mehmet Ozkaya 
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Problem: Sell Products Online 


= Create E-Commerce Web Application 


= Identify use cases and non-functional requirements 


= List products, add basket and ordering products. 
= Avaliable 7/24 


= Handle good amount of request per second 


= Provide acceptable latency for users 


Understand Problem 
= Understand E-Commerce Domain 
= Functional & non-functional requirements 


= Use cases 
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Understand E-Commerce Domain 


= Our Domain: E-Commerce 


= Understand Domain and Decompose small pieces 
= Use Cases 
= Functional Requirements 


Identify steps; 

= Requirements and Modelling 

= Identify User Stories 

= Identify the Nouns in the user stories 


= Identify the Verbs in the user stories 


TRACK YOUR ORDER LOCATE STORE 


HURRY UP! 


uPhone X 
ITS 29% OFF 


GET IT NOW 
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Understand E-Commerce Domain: Functional Requirements 


= List products 
= Filter products as per brand and categories 
= Put products into the shopping cart 


= Apply coupon for discounts and see the total cost 
all for all of the items in shopping cart 


= Checkout the shopping cart and create an order 


= List my old orders and order items history 


HURRY UP! 


uPhone X 
ITS 29% OFF 


GET IT NOW 


Mehmet Ozkaya 


59 


Understand E-Commerce Domain: User Stories (Use Cases) 


= As a user | want to list products 


= As a user | want to filter products as per brand and 
categories 


= As a user | want to put products into the shopping cart so 
that | can check out quickly later 


= As a user | want to apply coupon for discounts and see the 
total cost all for all of the items that are in my cart 


= As a user | want to checkout the shopping cart and create HURRY UP! 
an order uPhone X 

= As a user | want to list my old orders and order items TS 29% OFF 
history Ee 


= As a user | want to login the system as a user and the 
system should remember my shopping cart items 
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Understand E-Commerce Domain: Non-Functional Requirements 


= -jlities 


Scalability Availability Reliability 


Maintability Usability Eficiency 
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Request per Second and Acceptable Latency 


Requests/second Latency (Expected) 


2K 
20K 
100K 
500K 


0.5K 

12K 

80K <= 2 sec 
300K ? 
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Monolithic Architecture 


Benefits and Challenges of Monolithic Architecture. 
Design our E-Commerce application with Monolithic Architecture 


Mehmet Ozkaya 


63 


Architecture Design Journey 


modular Microservices 
Monolithic 
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Learn: Monolithic Architecture 


= Monolithic Architecture 

= When to use Monolithic Architecture 
= Benefits of Monolithic Architecture 

= Challenges of Monolithic Architecture 
= Monolithic Architecture Pros-Cons 


= Reference Architectures of Monolithic 
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What is Monolithic Architecture ? 


= Traditional approach to software development 
= Developing a complete application as a single unit 


= Most of legacy applications are mainly implemented as a 
monolithic architecture 


= Developed single codebase 
= Ul, Business and DB calls is in same codebase 


= All application ships with single big deployment with 
single jar/war file 


= Can't say old style arcitecture, still valid for particular 
scenarios 


= Advantages: Easy to get start and debug 


=" Disadvantages: Difficult to manage, Hard to implement 
new features 
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When to use Monolithic Architecture 


If you are building small application, still monolithic 
architecture is one of the best architecture. 


They're straightforward to: 


Build 

Test 

Deploy 
Troubleshoot 


Scale vertically (scale up) 


Simple to develop relative to microservices 


Easier to deploy as only a single jar/war file 
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When to use Monolithic Architecture 


= Small team at Founding Stage 
If you are a startup and your team is small like 2 to 5 members, 
you don't need to deal with the complexity of the high-overhead 
microservices architecture. 


= Simple application with Predictable Scale and Complexity 
If your application doesn’t require advanced scalability and the 
complexity is manageable, then a monolith architecture is the 
best option to start. 


= Proof of Concept and Quick Launch 
Building a proof of concept, like testing a new idea on market, 
that means your new products will pivot and evolve a lot over 
time, when you figure out what will be useful to your users. 


= No Microservices Expertise 
If your team has no prior experience with microservices 
architecture, that will really hard to ship your application 
effectively and timely. 
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Request per Second and Acceptable Latency — 


20K pi 
100K Sep = 
500K nE - 
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Benefits of Monolithic Architecture 


= Simple to Develop 
As long as the monolithic approach is a standard way of building 
applications, any engineering team has the right knowledge and 
capabilities to develop a monolithic application. 


= Easier debugging and testing 
Monolithic applications are much easier to debug and test. Since 
a monolithic application has a single code base, we can run end- 
to-end testing much faster. 


= Simple to deploy 
When it comes to monolithic applications, you do not have to 
handle many deployments, just one file or directory. Easier to 
deploy as only a single jar/war file is deployed. 
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Challenges of Monolithic Architecture 


= Become Complex over time - Hard to Understand 
It becomes too large in size with time and that’s why its difficult to 
manage. Application grows with adding new functionalities, a 
monolithic codebase can become extremely large and complex. 


= Hard to Making New changes 
lt is harder to implement new changes in such a large and complex 
application with highly tight coupling. Any code change affects the 
whole system. 


= Barrier to new technology adoption 
It is extremely problematic to apply a new technology because the 
entire application has to be re development due to the interlocking 
dependencies found in a monolith. 


= Difficult to Scale 
You can't scale components independently, the only option is the 
scaling the whole application. You can't scale individual 
componenis. 
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Learn: Design principles - KISS, YAGNI, DRY 


= DRY — Don’t Repeat Yourself 
Every piece of knowledge must have a single, unambiguous, 
authoritative representation within a system. Try to maintain 
the behavior of a functionality of the system in a single piece 
of code, it should not have duplicated code or design item. 


= KISS — Keep It Simple, Stupid 
Make your code or system simple. You should avoid 
unnecessary complexity. A simple code it's easier to maintain 
and easier to understand. 


= YAGNI — You Ain’t Gonna Need It 
This methodology said “Do the Simplest Thing That Could 
Possibly Work”. This principle says that you should not create 
features that it’s not really necessary. 
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Before Design — What we have in our design toolbox ? 


Architectures Patterns&Principles Non-FR 
e Monolithic e DRY e Availability 
Architecture e KISS e Small number of 
» YAGNI Concurrent User 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: First version of Monolithic Architecture 


Së Application 
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Before Design — What we have in our design toolbox ? 


Architectures Patterns&Principles Non-FR 
e Monolithic e DRY e Availability 
Architecture e KISS e Small number of 
» YAGNI Concurrent User 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design & Iterate : Monolithic Architecture 


= Add Database into our design Monolithic 1 Monolithic 2 


= Separate Client application 


Application 
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Evaluate : Monolithic Architecture - E-Commerce App 


Monolithic 1 Monolithic 2 


Benefits 

= Easy Development 

= Easy Debug and Test 
= Easy to Deploy 


Drawbacks Application 
= Highly tight coupling 

= Hard to Splitting the code 

= Violate Separation of concerns 
= Interlocking Dependencies 


without Layers of isolation 
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Problem: Code Become Too Complex Over Time 


Monolithic 1 Monolithic 2 


Problems 

, Become Complex over time 
« Hard to Understand Codes 
e Need Code Organization 


Solutions 

e Separate Ul, Business and Data Application 
Layers as logical layers 

e Layered Architecture 

e SOLID Design 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Layered (N-Layer) 
Architecture 


Benefits and Challenges of Layered (N-Layer) Architecture 


Design our E-Commerce application with Layered Monolithic 
Architecture 
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Problem: Code Become Too Complex Over Time 


Monolithic 1 Monolithic 2 


Problems 

, Become Complex over time 
« Hard to Understand Codes 
e Need Code Organization 


Solutions 

e Separate Ul, Business and Data Application 
Layers as logical layers 

e Layered Architecture 

e SOLID Design 
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Learn: Layered (N-Layer) Architecture 


= The layered architecture pattern is the most commonly 
used architecture pattern. Known as the n-tier 
architecture style or the multi-layered architecture 
style. 


= Organize the components of an application with similar 
functionalities into horizontal logical layers. Each layer 
performs a specific role within the application. 


= Still using Monolithic architecture separating horizontal 
logical layers, components are interconnected but don't 
depend on each other. 


= Organizing code for separation of concerns 


= Layers of isolation that layers can be modified and the 
change won't affect other layers. 
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Components of a Layered Architecture 


= Presentation Layer 
Responsible for user interactions with the software 
system, for example, a web app. 


= Application/Business Layer 
Handles aspects related to accomplishing functional 
requirements including use case implementations. 


= Database Layer 
Responsible for handling data, databases, such as a 
SQL database. 
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Design principles - Separation of Concerns (SoC) 


= Separation of concerns(SOC) is one of the core 
software design principle 
Separation of Concerns Separation of Concerns 


(only, from a different point of view 
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=" Separation of concerns is a design principle for 
separating a computer program into distinct sections 


= Isolate the software application into separate 
sections, manages complexity by partitioning the P 
software system 


= Distinguish between the concepts of layer and tiers css 
with certain responsibilities. 


= Elements in the software should be unique Glen 
s Limits to allocate responsibilities 


= Low-coupling, high-cohesion 


Design principles - SOLID 


= Single Responsibility 
Each of your components or modules should 
responsible only one functionality. 


= Open-Closed Principle 
When we design the system, it should able to extend 
without changing existing architecture. 


= Liskov Substitution Principle 
Systems can be substitute each other easily. In our 
case we can use plug-in services that we can shift them 
easily. 


= Interface Segregation Principle 
States that no code should be forced to depend on 
methods it doesn't use. 


= Dependency Inversion Principle 
States that high-level modules should not depend on 
low-level modules; both should depend on abstractions. 


Interface 
Segregation 


https://medium.com/bgl-tech/what-are-the-solid-design-principles-c61feff33685 
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Before Design — What we have in our design toolbox ? 


Architectures 


e Monolithic 
Architecture 


e Layered 
Architecture 


Patterns&Principles 


KISS 
YAGNI 


Seperation of 
Concerns (SoC) 


SOLID 


Non-FR 
Availability 


Small number of 
Concurrent User 


Maintainability 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: Layered Monolithic Architecture Steps Klee 


Monolithic 1 Monolithic 2 Monolithic 3 Monolithic 4 


| Client | Application Application 


Business | | 
Logic | Business Logic 


Application 


| > f 


L 


RDBMS 
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Design: Layered Monolithic Architecture 


Application 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Adapt: Layered Monolithic Architecture 


Java World 

, Apache Web Server 
e JZ2EE 

e MySQL 


NET World 

e IIS Web Server 
e Asp.Net 

e SQL Server 
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DEMO: Layered Monolithic Architecture Code Review 


ASP.NET 


DEMO: Code review of .NET Implementation 
e Asp.Net e-commerce web application 


e https://github.com/aspnetrun/run-aspnetcore-basics 
e https://github1s.com/aspnetrun/run-aspnetcore-basics 


Mehmet Ozkaya 91 


Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Layered Monolithic Architecture 


Benefits 

e Easy Development, Debug and Deploy 
e Horizontal Logical Layers 

e Separation of Concerns 


Drawbacks 

e Layers Dependent each other 

e Highly Coupling 

, Hard to maintanance 

e Complexity of codebase 

« Hard to Change libraries; i.e. 
Change orm tool with different library 
Requires to modify business layer. 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Highly Coupling Dependent Layers Pieter 


Problems 

e Layers are highly coupled and 
dependent each other 

e Code Organization hard to maintain 

e Locking of frameworks hard to change 


Solutions 
e Clean Architecture 
e The Dependecy Rule 


wx ` 
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Clean Architecture 


Benefits and Challenges of Clean Architecture 
The Dependency Rule of Clean Architecture 
Design our E-Commerce application with Clean Architecture 
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Problem: Highly Coupling Dependent Layers Pieter 


Problems 

e Layers are highly coupled and 
dependent each other 

e Code Organization hard to maintain 

e Locking of frameworks hard to change 


Solutions 
e Clean Architecture 
e The Dependecy Rule 


wx ` 


Add New N-FRs 

e Layered Architecture -> Maintability 

e Clean Architecture -> Flexibility, 
Testability 
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Way of Learning — The Course Flow 


Problem 


i i e Architecture Approaches e Fill Design Toolbox e Apply Saftware Tools 
bei Eeer e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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esign Adapt 


Learn: Clean Architecture 


Separates the elements of a design into circle levels. 


Clean architecture was created by Robert C. Martin and 
promoted on his blog, Uncle Bob. 


Organize code with encapsulates the business logic. 


F ` Dë, ` [_] Enterprise Business Rules 
Keep the core business logic and application domain at / E Jse Cases ` \ \ [F] Application Business Rules 
the center of the solution structure that independent with | | E See, | = NEN 
presentation and data access layers. 4 


Clean architecture divided into two main elements: the 
policies and the details. 

= The policies are the business rules and procedures 

= The details are the implementation code to carry out the policies 


Focus on the policies and business logics that build on 
project requirements https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 


The internal layers contains the business rules and has not 
dependency of any third-party library. 
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The Dependency Rule 


The dependencies of a source code can only point 
inwards. 


The Clean Architecture 


Code dependencies can only move from the outer levels 
inward. 


Code on the inner layers can have no knowledge of 
functions on the outer layers. 


Inner layer cannot have any information about elements of 
an outer layer. 


Classes, functions, variables, data format, or any entity 
declared in an outer layer must not be mentioned by the 
code of an inner layer. 


https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 
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Layers of Clean Architecture 


The Clean Architecture 


Enterprise Business Rules 


|_| Application Business Rules 


| Interface Adapters 
|_| Frameworks & Drivers 


Problem Learn Design 


Adapt 


The Clean Architecture Cone 


Abstract, General, Rarely Change 


[_] Enterprise Business Rules 
Application Business Rules 
CT Interface Adapters 
Frameworks & Drivers 


Concrete, Specific, Change Frequently 


https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 
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Benefits of Clean Architecture 


= Independent of Database and Frameworks 
The software is not dependent on an ORM or Database. You can change them easily. 


= Independence of Ul 
The Ul can change easily, without changing the rest of the system and business rules. 


= Testable 
It is naturally testable. You can test business rules without considering Ul, Database, Mock 
servers, etc. 


= Independence of any external agency 
In fact, your business rules simply don’t know anything at all about the outside world. 
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Before Design — What we have in our design toolbox ? 


Architectures 


Monolithic 
Architecture 


Layered Architecture 


Clean Architecture 


Patterns&Principles 


KISS 
YAGNI 


Seperation of 
Concerns (SoC) 


SOLID 


The Dependency 
Rule 


Non-FR 
Availability 


Small number of 
Concurrent User 


Maintainability 
Flexibility 
Testable 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: Clean Architecture 


Application 


Akchitecture 


Domain Layer 
Application Layer 
Infrastructure Layer 
Web UI Layer 
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Adapt: Clean Architecture 


Java World 

, Apache Web Server 
e J2EE 

e MySQL 


NET World 

e IIS Web Server 
e Asp.Net 

e SQL Server 


A 
N 


Domain Layer 
Application Layer 

Infrastructure Layer 
Web UI Layer 
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DEMO: Clean Architecture Code Review 


ASP.NET 


Mi 


Domain Layer 
Application Layer 

Infrastructure Layer 
Web UI Layer 


DEMO: Code review of Clean Architecture NET Implementation 
« Real-world - Clean Architecture 


e httos://github.com/aspnetrun/run-aspnetcore-realworld 
e https://github1s.com/aspnetrun/run-aspnetcore-realworld 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Clean Architecture 


Benefits 

e Easy Development, Debug and Deploy 

e Loosely Coupled Independent Layers 

e Flexible Logical Layers 

e Testable and Independent changable to 3rd parties libraries 


| e ` 


Drawbacks 


e Layers are independent but those are technical layers: 
e Domain, Infrastructure, Application and UI Layer 


e Vertical business logic implementation codes required to modify 
all layers: i.e. add to basket, checkout order use cases 


Domain Layer 
Application Layer 

Infrastructure Layer 
Web UI Layer 


, It is still Monolithic and has Scalability Issues 
e How many concurrent request can accommodate our design ? 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem = Learn H Design H Adapt 


Problem: Increased Traffic, Handle More Request 


Problems 

e Our E-Commerce Business is growing 

e Need to handle greater amount of 
request per second 

e Provide acceptable latency for users 


WAR 


ge, 
Clean 
Axchitectufe, 
N J 
Solutions 
e Scalabilitiy 
. Vertical and Horizontal Scaling 
« Scale Up and Scale Out a ask 
20K 12K 
e Load Balancer 
100K 80K <= 2 S6C 
500K 300K 


R 
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scalability 


Vertical Scaling - Horizantal Scaling of Application 
Calculate How many concurrent request can accommodate our design ? 
Load Balancer with Consistent Hashing 
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Problem = Learn H Design H Adapt 


Problem: Increased Traffic, Handle More Request 


Problems 

e Our E-Commerce Business is growing 

e Need to handle greater amount of 
request per second 

e Provide acceptable latency for users 


WAR 


ge, 
Clean 
Axchitectufe, 
N J 
Solutions 
e Scalabilitiy 
. Vertical and Horizontal Scaling 
« Scale Up and Scale Out a ask 
20K 12K 
e Load Balancer 
100K 80K <= 2 S6C 
500K 300K 


R 
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Understand E-Commerce Domain: Non-Functional Requirements 


= -jlities 


Scalability Availability Reliability 


Maintability Usability Eficiency 
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Scalability - How many concurrent request can accommodate our 
design ? 


Requests/second Latency (Expected) 


2K 0.5K 

20K 12K 

100K 80K <= 2 sec 
500K 300K ? 
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Scalability - Vertical Scaling - Horizontal Scaling 


= Scalability is the number of requests an application can 
handle 


= Measured by the number of requests and it can effectively eesti 
support simultaneously. eer 


= |f no longer handle any more simultaneous requests, it has Horizontal Scaling 
reached its scalability limit. piinia 


Vertical eng 


= To prevent downtime, and reduce latency, you must EI Leileiel 


scale 
—— 
a Horizontal scaling by adding more machines https://www.webairy.com/horizontal-and-vertical-scaling/ 


= Horizontal scaling and vertical scaling both involve adding 
resources to your computing infrastructure 


= Vertical scaling by adding more power 
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Vertical Scaling - Scale up 


= Vertical scaling is basically makes the nodes stronger. 


= Make the server stronger with adding more hardware. Adding more Vertical Scaling 
resources to a single node. ( Increase size of instance (RAM 


CPU etc.) ) 


= Make optimization the hardware that will allow you to handle more 
requests. 


= Vertical scaling keeps your existing infrastructure but adding more 
computing power. 


= Your existing code doesn't need to change. 


= Adding additional CPU, RAM, and DISK to cope with an increasing 
workload. 


= By scaling up, you increase the capacity of a single machine. And it has 
limits. That is named Scalability Limits. EI 

= Because even the hardware has maximum capacity limitations. 

= For handling millions of request, we need horizontal scaling or scaling out. 
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Horizantal Scaling - Scale out 


= Horizontal scaling is splitting the load between different servers. 


= Simply adds more instances of machines without changing to existing 


specifications. Horizontal Scaling 
= Share the processing power and load balancing across multiple ( Add more instances 
machines. 


= Horizontal scaling means adding more machines to the resource pool. 


= Preferred way to scale in distributed architectures. 


" Scaling horizontally gives you scalability but also reliability. A e H H 


= When splitting into multiple servers, we need to consider if you have a 


state or not. 
eg Ai 


= if we have a state like database servers, than we need to manage more 
considerations like CAP theorem. 
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Learn: Load Balancer 


= Balance the traffic across to all nodes of our applications. 


= Spread the traffic across a cluster of servers to improve 
responsiveness and availability. 


= Load Balancer sits between the client and the server. 


= Load Balancer is accepting incoming network and 
application traffic. 


= Distributing the traffic across multiple backend servers using 
different algorithms. 


= Load Balancers should be fault tolerance and improves 


availability. eee 


= Mostly uses the consistent hashing algorithms. Consistent 
hashing is an algorithms for dividing up data between 
multiple machines. 


= It solves the horizontal scalability problems. Don’t have to re- 
arrange all the keys. 
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Before Design — What we have in our design toolbox ? 


Architectures 


Monolithic 
Architecture 


Layered Architecture 


Clean Architecture 


Patterns&Principles 


KISS 
YAGNI 


Seperation of 
Concerns (SoC) 


SOLID 


The Dependency 
Rule 


Horizontal Scaling 
Load Balancer 


Non-FR 
Availability 


High number of 
Concurrent User 


Maintainability 
Flexibility 
Testable 
Scalability 
Reliability 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: Scalability — Horizontal Scaling 


Application 
Horizontal Scaling 
Application Servers 


Domain Layer 
Application Layer 

Infrastructure Layer 
Web UI Layer 
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Load Balancer 
« Apache LB 
e NGINX 


Application 
Horizontal Scaling 
Application Servers 


Application Server 
« Single JAR / WAR File 
e Tomcat Container 


Database 
e Oracle 
Domain Layer 
e Postgres Application Layer 
e SQL Server Infrastructure Layer 
` MySQL Web UI Layer 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Clean Architecture 


Benefits 
e Easy Development, Debug and Deploy 


e Loosely Coupled Independent Layers 


e Flexible Logical Layers 


e Testable and Independent changable to 3rd parties libraries 


KE 
Drawbacks & 


e Layers are independent but those are technical layers: | 
e Domain, Infrastructure, Application and UI Layer AA 
- Vertical business logic implementation codes required to 


modify all layers: i.e. add to basket, checkout order use cases 


Application 


Horizontal Scaling 
Application Servers 


Domain Layer 
Application Layer 
Infrastructure Layer 
Web UI Layer 


e It is still Monolithic and has Scalability Issues 
e How many concurrent request can accommodate our design ? 
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Pain Points of Clean Architecture 


= Context Switching New Feature 
When we were working on a feature and needed to work on 
any combination of data access, domain or application logic, 
we had to switch contexts into different software project. 


= We had to remember and re-visit codes from other folder 
and continue with totally different code base. The folder 
structure requires DDD-bounded contexts approaches. 


= Vertical Slices 
When adding a feature in an application, we are developing 
into almost all layers in the application code. 


BIS ILIA 


= Changing the user interface, adding new Use Case classes 
into Application Layer, adding fields to models, modifying Data 
Access Codes, and so on. 


= So that means we are highly couple with vertically slice 
when developing features. 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Agility of New Features, Split Agile Teams To 


Problems 

Our E-Commerce Business is growing 
Business teams are separated teams as per 
departments; Product, Sale, Payment.. 

And all teams wants to add new features to Eien 
compete the market 

Codebase not allowed to manage it $ 
Context Switching and Vertical Slices bist = 
problems on Clean Architecture 


Solutions Së 


, Modular Monolithic Architecture 


Application 


Horizontal Scaling 
Application Servers 


sote LIHA 
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Modular Monolithic 
Arcihtecture 


Benefits and Challenges of Modular Monolithic Architecture 
The Dependency Rule of Modular Monolithic Architecture 
Design our E-Commerce application with Modular Monolithic Architecture 
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Architecture Design Journey 


Modular . , 
ae Microservices 
Monolithic 
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Problem: Agility of New Features, Split Agile Teams To 


Problems 

Our E-Commerce Business is growing 
Business teams are separated teams as per 
departments; Product, Sale, Payment.. 

And all teams wants to add new features to Eien 
compete the market 

Codebase not allowed to manage it $ 
Context Switching and Vertical Slices bist = 
problems on Clean Architecture 


Solutions Së 


, Modular Monolithic Architecture 


Application 


Horizontal Scaling 
Application Servers 


sote LIHA 
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Learn: Modular Monolithic Architecture 


= Modular Monolithic Architecture 
= When to use Modular Monolithic Architecture 
= Benefits of Modular Monolithic Architecture 


= Challenges of Modular Monolithic Architecture 


= Modular Monolithic Architecture Pros-Cons 


= Reference Architectures of Modular Monolithic 
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What is Modular Monolithic Architecture ? 


= Modular monolithic architecture divided our application 
logic into modules and each module will be independent 
and isolated and should have its own business logic, 
database schema. 


= Each module can follow their own logical separations, 
layered architecture style or clean architecture. 


= The Modular Monolith architecture breaks up the code into 


Application 


Module 1 Module 2 Module 3 


independent modules, each module encapsulates their 


own features. 


Data 


= Modules are represents Bounded Context of our Access 


application domain and we group features of Domain 
contexts in modules. 


= Reduces the dependencies of a module and we can 
develop or modify a module without it effecting other 
modules. 
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Vertical Slices with Modular Monolithic Architecture 


= Instead of using layered architecture with horizontal logical 
layers, we can organize our code across vertical slices of Feature1 Feature? ` Feature? 


business functionality. 


= These slices are determined based on business demands, 
rather than enforced by technical constraints. 


= When we add or change a feature in an application, our 
changes are scoped to the area of business concern not 
technical logical layers. 


= With the modular monolith architecture, organize our codes 
as a vertical slices, and as our system continues to grow, 
organizing our code around of business functionalities into 
Modules. 

= Modules can be a potential microservices when need to 
independently deployed and scale in the future refactorings 
our architecture. 


ae ILIA 
BINNS JEHA 
BINS JEJA 
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E-Commerce with Modular Monolithic Architecture 


Example Use Cases 
Application 


= Listing products = Product 8 
Product Basket 


Module 


= Add to basket = Basket 
Module 


= Checkout order = Order 
Module 


a EH 
Main Benefits 7 g g 8 
ata a a 
= Reduced complexity Access Access Access 


= Easier to refactor 


s}onpoid Dune 
yo4Seq O} ppe 
Japso jnoydeys 


= Better for teams 
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Benefits of Modular Monolithic Architecture 


= Encapsulate Business Logic 
Business logics are encapsulated in Modules and it enables high reusability, while data remains consistent 
and communication patterns simple. 


= Reusable Codes, Easy to Refactor 
For large development teams, developing modular components of an application will increase reusability. 
Modular components can be reused that can help teams establish a single source of truth. 


= Better-Organized Dependencies 
With modular monoliths architecture, application dependencies will be more organized and visible. This will 
help developers to easily assess which parts of the application require which dependencies. 


= Less-Complex than Microservices Architecture 
Easier to manage a modular monolith rather than hundreds of microservices, because Modular Monolithic 
comes with basic underlying infrastructure and operational costs low. 


= Better for teams 
Easier for developers to work on different parts of the code. with Modular Monolithic architecture, we can 
divide our developer teams effectively and implement business requirements with minimum affect to each 
other. 
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Challenges of Modular Monolithic Architecture 


= Can't diversifying technology 
Modular monoliths don't provide all benefits of microservices. If you need to diversifying technology and 
language choices, you can't do it with Modular Monolithic Architecture. These types of polyglot technology 
stacks can't use with Modular Monolithic Architecture. 


= Can't Scale and Deploy Independently 
Since the application is a single unit, it can't be scale separated parts or deploy independently like 
microservices. And this kind of applications has to move microservices due to reaching out scalability limits 
and also performance issues. 
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When to use Modular Monolithic Architecture 


= Strict Consistency is Mandatory Cases 
For many companies unable to make the move to microservices, due to their database and data not 
appreciate for distributed architecture. 


= For example if your application store high important data like debit on bank account, then you need 
strong data consistency that means your data should be correct for every time, if you got any exception 
you have to rollback immediately. 


= Modernization 
If you already have a big complex monolithic application running, the modular monolith is the perfect 
architecture to help you refactor your code to get ready for a potential microservices architecture. 


= Instead of jumping into microservices, you can move modular monolithic without effecting your business 
and get benefits like soeed up with a well-factored modular monolith. 


= Green Field Projects 
A modular monolith allow you to learn your domain and pivot your architecture much faster than a 
microservices architecture. You won't have to worry about things like Kubernetes and a services mesh 
at day1. Your deployment topology will be drastically simplified. 
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Monolith First Approaches, Martin Fowler 


= Martin Fowler: Monolithic First, 2015 


= https://martinfowler.com/bliki/MonolithFirst.html 


= Successful microservice stories have started with a 
monolith 


= A system that was built as a microservice system from 
scratch, it has ended up in serious trouble. 


s}onpoud Dunsu 


= WMicroservices are a useful architecture, but it incurs a 
significant complexity, which means they are only useful 
with more complex systems. 


= Consider Yagni. When you begin a new application, how sure 
are you that it will be useful to your users? 


= Starting with microservices works well if you come up with 
good, stable boundaries between the services which is 
BoundedContexts. 


Product 


siness Logic | 


yoxseq 0} ppe 
Japso jnoydeyd 
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Monolith First Approaches, Sam Newman 


= Sam Newman — Building Microservices, 2nd Edition 


= https://samnewman.io/books/building_microservices/ 


= He agrees with the Martin Fowler approach which is ~ Product 
recommend beginning development of new projects and 
systems as a Single deployable unit — the monolith. 


= Leveraging microservices only if you can become convinced 
of the benefits for your system, not as a default for every 
project. 


siness Logic | 


s}ənpoud unsi 
Jeep 0} ppe 
1Əəp10 }noyəƏəyə 


= A monolithic architecture is a choice, and a valid one at that. 
I'd go further and say that in my opinion it is the sensible 
default choice as an architectural style. In other words, | am 
looking for a reason to be convinced to use microservices, 
rather than looking for a reason not to use them. 
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Monolith First Approaches, Mehmet Ozkaya 


= Monolithic architecture does not means that the system is poorly 
designed or bad. Instead 


= If you follow Modular approach, It will comes with lots of similar 
benefits with microservices like re-usability, easy to Refactor, Better 
organized dependencies and teams. 


= So Should we always start with Monolith First Approaches ? — NO 


= How we can decide ? If 


an 
= 
3 
Q 
Ki 
= 
[e] 
Qa 
E 
Q 
= 
H 


= Strong Consistency is Mandatory && Independent Scale and 
Deploy is not Required = Modular Monolithic 


= Strong Consistency is not Mandatory, Eventual Consistency is 
OK && Independent Scale and Deploy is Required = 
Microservices 


Product 


Japso }noyə2Əəy2 
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Monolithic Architecture Vertical Considerations 


Modular Microservices 
Monolithic 


m i Adapt 
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Communication of Monolithic Architecture 


= Monolithic application sitting in the same server with all modules. 
So we don’t need to make any network call. 


= Itis very easy and fast to communicate between modules. 
= The communication will be Inter-Process Communication. 


= Inter-process communication is the mechanism provided by the 
operating system that allows processes to communicate with 
each other. 


= |t processes to communicate with each other by method calls into 
the code. 


inter-process 
communication 
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Monolithic Architecture Vertical Considerations sat 


Mocu ar Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Transaction Management of Monolithic Architecture 


= Transaction management in Monolith architecture is quite easy compared 
to Microservice Architecture. Many frameworks or languages contains 
some mechanism for transaction management. 


= These mechanism have a single database of the whole application. function place order() 
They are developed for scenarios where all transactions are running ona do payment 


single context. r k 
= Simply commit and rollback operations with these mechanism in monolith ecrease_stoc 


architectures. send_shipment 
= Transactions operated in the transaction scope are kept in memory generate_ bill 
without writing to the database until they are committed, and if a Rollback update order 


is made at any time, all transactions in the scope are deleted from memory 
and the transaction is canceled. 


= When Commit is written to the database, the transaction is completed 
successfully. 
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Monolithic Architecture Vertical Considerations sant 


sik! Microservices 
Monolithic 
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Deployments of Monolithic Architecture 


= Single code base harder to implement new changes especially in a large and complex application. 


= Any code change affects the whole system. Even the smallest change requires full deployment of 
the entire application. 


= Pain point of Monolithic Architectures that is not reliable that a single bug in any module can bring 
down the whole monolithic application. 


Large Development 
Teams 


Single Code 


a Deployment pipeline 
Base 


| Producton 
Seal 
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Problem: Agility of New Features, Split Agile Teams To 


Problems 

Our E-Commerce Business is growing 
Business teams are separated teams as per 
departments; Product, Sale, Payment.. 

And all teams wants to add new features to Eien 
compete the market 

Codebase not allowed to manage it $ 
Context Switching and Vertical Slices bist = 
problems on Clean Architecture 


Solutions Së 


, Modular Monolithic Architecture 


Application 


Horizontal Scaling 
Application Servers 


sote LIHA 
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Before Design — What we have in our design toolbox ? 


Architectures 


e Monolithic 
Architecture 


e Layered Architecture 
e Clean Architecture 


e Modular Monolithic 
Architecture 


Patterns&Principles 


KISS 
YAGNI 


Separation of 
Concerns (SoC) 


SOLID 


The Dependency 
Rule 


Horizontal Scaling 
Load Balancer 


Monolithic-First 
Strategy 


Non-FR 
Availability 


High number of 
Concurrent User 


Maintainability 
Flexibility 
Testable 
Scalability 
Reliability 
Re-usability 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: Modular Monolithic Architecture 


Application 


Product Module Order Module 


Basket Module Payment Module 


Shipment Module Reporting Module 
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Application 


Product Basket 


Load 
Balance 


RDBMS 


Data Product| | Order 
Access Access Schema) \Schema 


Japso jnoyoeys 
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Evaluate: Complexity of Presentation Ul Operations 


Benefits 

e Easy Development, Debug and Deploy 

e Encapsulated Vertical Slices Modules 

Drawbacks 

e Ul operations are handled in our big monolithic application. 

e With adding new features, the Complexity of Presentation UI Operations are going to be nightmare. 
e Ul layer is generated from server-side, every module is trying to generate their own page. 

e Ul Layer has different minor requirements, requires full deployment. 

e Business teams has UI related requirements are increased. 


Application 


Product Basket 


Q e Load d 
Zë Balance, 
d siness Logic siness Logic 


Data 


Access 
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Problem: Improve Customer Experience with SPA Lee? 


Problems 
e Our E-Commerce Business is growing 
e Improved customer experience with 
Separated UI and Omnichannel EE 


, Responsive Pages with SPA SES geg 
e Omnichannel expectations | 
5 CES 
Solutions | oo ES e = 
Access Access | Schema \Schema 


e Separated Presentation with SPA 
e Separate FrontEnd - BackEnd 


e Headless Architecture 


RDBMS 


jeyseq 0} ppe 
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Headless Architecture and Separated UI-SPA 


= Headless architecture separates the frontend from the backend 
layer of the application. Separates Ul and business logic. 


= Headless architecture emphasizes mainly decoupling frontend — 


backend layers, and it is the first step before moving to 
= |t uses APIs to connect the front and backends applications. 
= Application programming interfaces (APIs) are software 


intermediaries that enable communication between applications. 1" wen 


= REST APIs which created from Backend application are consumes 
from the Frontend Application. These API consume operations are 
handled in SPA application in frontend side. 


= Single page applications (SPA) are applications contained in a 
single web page without having full-page reload, and able to update 
some portion of the page with responsive way. 
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Benefits of Headless Architecture 


= Headless architecture separates the frontend from the backend 
layer of the application. Separates Ul and business logic. 


= Flexible to use any frontend framework or modern approach to 
web developments 


= Easily share services across all channel heads e 

= Update frontend independently of the services 

= Innovate and experiment with new channels 
= Better performance Tse 
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Before Design — What we have in our design toolbox ? 


Architectures 


e Monolithic 
Architecture 


e Layered Architecture 
e Clean Architecture 


e Modular Monolithic 
Architecture 


e Headless 
Architecture 


Patterns&Principles 


KISS 
YAGNI 


Separation of 
Concerns (SoC) 


SOLID 


The Dependency 
Rule 


Horizontal Scaling 
Load Balancer 


Monolithic-First 
Strategy 


Separated Ul 


Non-FR 
Availability 


High number of 
Concurrent User 


Maintainability 
Flexibility 
Testable 
Scalability 
Reliability 
Re-usability 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Ul 
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Adapt: Modular Monolithic Architecture with SPA 


Load Balancer 
« Apache LB 
e NGINX 


Frontend SPAs 
e Angular 

e Vue 

e React 


Backend Application 
e Single JAR / WAR File 
e Tomcat Container 


Database 
e Oracle 


e Postgres 
e SQL Server Mehmet Ozkaya 156 


DEMO: Modular Monolithic Architecture with SPA Code Review 


Product Basket 


siness Logic 
| [Product 
: (Schema; {Schema 


Data 
Access 


s}ənpoud Busy 
yoySeq 0} ppe 
1əp10 }noyəəyə 


DEMO: Kamil Grzybek — Modular Monolithic with DDD 
e httos://github.com/kgrzybek/modular-monolith-with-ddd 
e httos://github1s.com/kgrzybek/modular-monolith-with-ddd 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Modular Monolithic Architecture with SPA 


Benefits 

e Easy Development, Debug and Deploy 

e Encapsulate Business Logic 

- Reusable Codes, Easy to Refactor E 

, Better-Organized Dependencies and Teams 3 
Q 


e Update frontend independently, Flexible Ul 


Drawbacks 

Scalability Limits, Database Can't Scale 
We have 1 big relational database that can't scale and become 
bottleneck for our architecture. Million request got timeout exception. 
It is still Monolithic and has Scalability Issues 

Can't Scale Modules Independently 

Can't Deploy Modules Independently 

It is still Monolithic and has Deployment Issues 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Scale and Deploy Independently Ss 


Problems 

Our E-Commerce Business is growing 

Business teams are separated teams as per departments; Product, Sale, Payment. 
Teams wants to agile and add new features immediately to compete the market 
Innovate and experiment with new features as soon as possible 

Deploy features immediately, not waiting for deployment dates 

Flexible scale for market peek times like blackfriday sales 

Handle and process millions of request in a acceptable latency with better performance. 
Required not only technology change but also organizational change is mandatory. 


Solutions 
e Microservices Architecture 


161 


Microservices 
Architecture 


Benefits and Challenges of Microservices Architecture 
When to use Microservices Architecture 
Design our E-Commerce application with Microservices Architecture 
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Architecture Design Journey 


Modular 
Monolithic 


Microservices 
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Problem: Scale and Deploy Independently Ss 


Problems 

Our E-Commerce Business is growing 

Business teams are separated teams as per departments; Product, Sale, Payment. 
Teams wants to agile and add new features immediately to compete the market 
Innovate and experiment with new features as soon as possible 

Deploy features immediately, not waiting for deployment dates 

Flexible scale for market peek times like blackfriday sales 

Handle and process millions of request in a acceptable latency with better performance. 
Required not only technology change but also organizational change is mandatory. 


Solutions 
e Microservices Architecture 
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Learn: Microservices Architecture 


= Microservices Architecture 

= When to use Microservices Architecture 
= Benefits of Microservices Architecture 

= Challenges of Microservices Architecture 
= Microservices Architecture Pros-Cons 


= Reference Architectures of Microservices 
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What are Microservices ? CT 


Microservices are small, independent, and loosely 
coupled services that can work together. 


Each service is a separate codebase, which can be 
managed by a small development team. 


Monolithic Macroservices Microservices 


Microservices communicate with each other by using well- 
defined APIs. 


Microservices can be deployed independently and 
autonomously. 


Application 


Microservices can work with many different technology 
stacks which is technology agnostic. 


Microservices has its own database that is not shared with 
other services. 
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What is Microservices Architecture ? 


= From Martin Fowlers Microservices article: 


The microservice architectural style is an approach to developing a single application as a suite of small 
services, each running in its own process and communicating with lightweight mechanisms, often an 
HTTP or gRPC API. 


= Microservices are built around business capabilities and independently deployable by fully automated 
deployment process. 


= Microservices architecture decomposes an application into small independent services that 
communicate over well-defined APIs. Services are owned by small, self-contained teams. 


= Microservices architecture is a cloud native architectural approach in which services composed of many 
loosely coupled and independently deployable smaller components. 


= Microservices have their own technology stack, communicate to each other over a combination of REST 
APIs, are organized by business capability, with the bounded contexts. 


= Following Single Responsibility Principle that referring separating responsibilities as per services. 
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Microservices Characteristics 


= From Martin Fowlers Microservices article: 


= Componentization via Services 

= Organized around Business Capabilities 
= Products not Projects 

= Smart endpoints and dumb pipes 

= Decentralized Governance 

= Decentralized Data Management 

= Infrastructure Automation 


= Design for failure 
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Benefits of Microservices Architecture 


= Agility, Innovation and Time-to-market 
Microservices architectures make applications easier to scale 
and faster to develop, enabling innovation and accelerating ;-------- 
time-to-market for new features. 


= Flexible Scalability 
Microservices can be scaled independently, so you scale out 
sub-services that require less resources, without scaling out 
the entire application. 


= Small, focused teams 
Microservices should be small enough that a single feature 
team can build, test, and deploy it. 


Aemayey dY 


= Small and separated code base 
Microservices are not sharing code or data stores with other 
services, it minimizes dependencies, and that makes easier 
to adding new features. 
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Benefits of Microservices Architecture -2 


=" Easy Deployment 
Microservices enable continuous integration and continuous 


if something doesn’t work. 


= Technology agnostic, Right tool for the job 
Small teams can pick the technology that best fits their 
microservice and using a mix of technology stacks on their 
services. 


= Resilience and Fault isolation 
Microservices are fault toleranced and handle faults correctly 
for example by implementing retry and circuit breaking 
patterns. 


Aemayed Idy 


= Data isolation 
Databases are separated with each other according to 
microservices design. Easier to perform schema updates, 
because only a single database Is affected. 
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Challenges of Microservices Architecture 


= Complexity 
Each service is simpler, but the entire system is more 
complex. Deployments and Communications canbe ~— ;--------- 
complicated for hundreds of microservices. 


= Network problems and latency 
Microservice communicate with inter-service communication, 
we should manage network problems. Chain of services 
increase latency problems and become chatty API calls. 


= Development and testing 
Hard to develop and testing these E2E processes in 
microservices architectures if we compare to monolithic 
ones. 


Aemayey dY 


= Data integrity 
Microservice has its own data persistence. Data consistency 
can be a challenge. Follow eventual consistency where 
possible. 
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Challenges of Microservices Architecture -2 


= Deployment 
Deployments are challenging. Require to invest in quite a lot 
of devops automation processes and tools. The complexity ;--------- 
of microservices becomes overwhelming for human 
deployment. 


= Logging & Monitoring 
Distributed systems are required to centralized logs to bring 
everything together. Centralized view of the system to 
monitor sources of problems. 


s Debugging 
Debugging through local IDE isn’t an option anymore. It 
won’t work across dozens or hundreds of services. 
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When to Use Microservices Architecture 


= Make Sure You Have a “Really Good Reason” for Implementing Microservices 
Check if your application can do without microservices. When your application requires agility to 
time-to-market with zero-down time deployments and updated independently that needs more 
flexibility. 


= lterate With Small Changes and Keep the Single-Process Monolith as Your “Default” 
Sam Newman and Martin Fowler offers Monolithic-First approach. Single-process monolithic 
application comes with simple deployment topology. Iterate and refactor with turning a single 
module from the monolith into a microservices one by one. 


= Required to Independently Deploy New Functionality with Zero Downtime 
When an organization needs to make a change to functionality and deploy that functionality without 
affecting rest of the system. 


= Required to Independently Scale a Portion of Application 
Microservice has its own data persistence. Data consistency can be a challenge. Follow eventual 
consistency where possible. 
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When to Use Microservices Architecture -2 


= Data Partitioning with different Database Technologies 
Microservices are extremely useful when an organization 
needs to store and scale data with different use cases. = = ;-------- 
Teams can choose the appropriate technology for the 
services they will develop over time. 


= Autonomous Teams with Organizational Upgrade 
Microservices will help to evolve and upgrade your teams 
and organizations. Organizations need to distribute 
responsibility into teams, where each team makes decisions 
and develops software autonomously. 
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When Not to Use Microservices 
Anti-Patterns of Microservices 


= Don’t do Distributed Monolith 
Make sure that you decompose your services properly and respecting the 
decoupling rule like applying bounded context and business capabilities principles. 


= Distributed Monolith is the worst case because you increase complexity of your 
architecture without getting any benefit of microservices. 


= Don’t do microservices without DevOps or cloud services 
Microservices are embrace the distributed cloud-native approaches. And you can 
only maximize benefits of microservices with following these cloud-native principles. 
= CI/CD pipeline with devops automations 
= Proper deployment and monitoring tools 
= Managed cloud services to support your infrastructure 
= Key enabling technologies and tools like Containers, Docker, and Kubernetes 
= Following asnyc communications using Messaging and event streaming services 


Catalog 


, Shopping 
Cart 


Aemeyed Idy 
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When Not to Use Microservices 


= Limited Team sizes, Small Teams 
If you don’t have a team size that cannot handle the 
microservice workloads, This will only result in the delay of ;-------- 
delivery. 


= For a [small team, a microservice architecture can be hard to 
justify, because team is required just to handle the 
deployment and management of the microservices 
themselves. 


= Brand new products or startups 
If you are working on a new startup or brand new product 
which require significant change when developing and 
iterating your product, then you should not start with 
microservices. Leer Le 


Aemayed Idy 


= Microservices are so expensive when you re-design your 
business domains. Even if you do become successful enough 
to require a highly scalable architecture. 


= The Shared Database anti-pattern Mehmet Ozkaya 176 


Monolithic vs Microservices Architecture Comparison 


= Application Architecture 
Monolith has a simple straightforward structure of one 
undivided unit. Microservices have a complex structure that 
consists of various heterogeneous services and databases. 


Large Development 
Teams 


Monolithic 


= Scalability 
Monolithic application is scaled as a whole single unit, but 
microservices can be scaled unevenly. encourages 
companies to migrate their applications to microservices. 


j Deployment Organized Microservices 
Monolithic application provides fast and easy deployment of [Development Teams 
the whole system. Microservices provides zero-downtime Prodact 
deployment and Cl/CD automation. Ge 


= Development team 
If your team doesn't have experience with microservices and 
container systems, building a microservices-based 
application will be difficult. 


Product 
Service 


(UML 
> Basket , | Product 
Code 
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Architecture Comparison 


Monolithic Application 


Aemayed Idy 
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Deployment Comparison 


Monolithic 


Large Development 
Teams 


Problem Learn Design Adapt 


Microservices 


Organized 
Development Teams 


Product 
Team 
Basket 
Team 


Product 
Service 


>| Deployment pipeline $ 


>| Deployment pipeline H 
sl Deployment pipeline H 


> 


Basket 
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Product 
Service 


Product 
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The Database-per-Service Pattern 


= Core characteristic of the microservices architecture is the 
loose coupling of services. every service should have its 
own databases, it can be polyglot persistence among to 
microservices. 


= E-commerce application. We will have Product - Ordering 
and SC microservices that each services data in their own 
databases. Any changes to one database don’t impact other : 
microservices. 


= The service’s database can’t be accessed directly by other 
microservices. Each service's persistent data can only be 
accessed via Rest APIs. 
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Benefits of the Database-per-Service Pattern 
with Polygot Persistence 


= Data schema changes made easy without impacting other 
microservices. 


= Each database can scale independently. 


= WMicroservices domain data is encapsulated within the service. 


= If one of the database server is down, this will not affect to 
other services. 


= Polyglot data persistence gives ability to select the best 
optimized storage needs per microservices. 


mm em mm em em em em em em em em em em em em em em em em | = 
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E-Commerce with Database-per-Service Pattern 


and Polygot Persistence 


Product service using NoSQL document 
database for storing catalog related data. 


Shopping cart service using a distributed 
cache that supports its simple, key-value 
data store. 


Ordering service using a relational 
database to handle the rich relational 
structure. 


NoSQL databases able to massive scale 
and high availability, and also schemaless 
structure give flexibility. 
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Problem: Scale and Deploy Independently Ss 


Problems 

Our E-Commerce Business is growing 

Business teams are separated teams as per departments; Product, Sale, Payment. 
Teams wants to agile and add new features immediately to compete the market 
Innovate and experiment with new features as soon as possible 

Deploy features immediately, not waiting for deployment dates 

Flexible scale for market peek times like blackfriday sales 

Handle and process millions of request in a acceptable latency with better performance. 
Required not only technology change but also organizational change is mandatory. 


Solutions 
e Microservices Architecture 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot 
Persistence 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology 
agnostic 


Data isolation 


Resilience and 
Fault isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Adapt: Microservices Architecture 


Frontend SPAs 
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Backend Microservices 
e Java — Spring Boot 

e Nei — Asp.net 

e JS — NodeJS 

e Python — Django, Flask 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservices Architecture 


Main Considerations 
Decomposition — 
Breaking Down 
Services 
Communications 
Data Management 


Client App 


Transaction 
Management 
Deployments 
Resilience 


Key-Value 
i 
| 


Relational 


> Relational 
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Architecture Design — Vertical Considerations 


eieiei Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 
Transaction Management 
Deployment 


Resilience 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Break Down Application into Microservices To 


Problems 

e Our E-Commerce Business is growing 
to compete the market 

, Required Independent Scale and Deployments 

e We should clearly identify microservices which parts 
could be independent scale and deploy 


| Shopping | 


Cart 


| Ordering l > 
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Solutions 
e Microservices Decomposition Patterns 


Pe eeee SPSS SS SESSA SSS ee see's © 


Decomposition of 
Microservices Architecture 


Breaking Down Application into Microservices 

Microservices Decomposition Patterns 

Decomposing Applications for Independent Deployability and Scalability 

Breaking Down our E-Commerce application with Microservices Decomposition Patterns 
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Architecture Design — Vertical Considerations 


Modular : : 
See Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 
Transaction Management 


Deployment 


Resilience 
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Problem: Break Down Application into Microservices To 


Problems 

e Our E-Commerce Business is growing 
to compete the market 

, Required Independent Scale and Deployments 

e We should clearly identify microservices which parts 
could be independent scale and deploy 


| Shopping | 


Cart 


| Ordering l > 
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Solutions 
e Microservices Decomposition Patterns 
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Microservices Decomposition Path 


E-Commerce Identify 
Bounded Decompose Kee i 
Domain e Microservice 
' Contexts Strategies 
Analysis Boundaries 


Passes eeseeeanuy 
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Why we need to Decompose ? 


= What is the main reason behind the decomposition of 
microservices ? provide to Scale Independently. 


= Main benefits of microservices are "Independent Scale and 
Deployments". 


= Clearly identify microservices which parts could be required -------------/-----\-----4--------\--------- 
independent scale and deploy. 


= Design Principle: Decompose services by scalability 
requirements 


= Applications are consist of multiple modules or services, with 
different requirements for scaling. 


=» Example: Our e-commerce application have a public-facing 
website and a separate administration website. 


= 2 services required different scalability requirements. 
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The Scale Cube 


= X-Axis: Horizontal Duplication and Cloning of services and 
data 


= Y-Axis: Functional Decomposition and Segmentation — 
Microservices 


= Z-Axis: Service and Data Partitioning along Customer 
Boundaries - Shards/Pods 


= Functional decomposition can be achieved by decoupling 
your architecture into functions with Y-axis. 


= WMicroservices is an example for functional decomposing. 


= Y-axis scaling splits the application into multiple, different 
Services. 


= Combining both X and Y-Axis scaling with microservices 
architecture can give better scalability. 


3 Dimensions of Scaling 


Y axis - fuctional 
decomposition 
Scale by splitting 
small services 


X axis - horizontal Z axis - data partioning 
duplication Scale by splitting data 
Scale by Clonning 
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Microservices Decomposition Pattern — 
Decompose by Business Capability 


In Microservices Architecture, split the application as a 
set of loosely coupled services. 


Business Capabilities 


Product — 
catalog ry 


Delivery 


2 Prerequisite of decomposition of microservices: 


Services must be cohesive. A service should implement a 
small set of strongly related functions. 


Services must be loosely coupled - each service as an 
API that encapsulates its implementation. 


"Decompose by Business Capability" pattern offer: 
Define services corresponding to business capabilities. 


A business capability is a concept from business 
architecture modeling. 


FeV SSE SEBstesseeseeerts* 
Leese wm, em em em, em, em. em em, em, em em, em, em, em. em, en, el 


A business service should generate value. 
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Microservices Decomposition Pattern — 
Decompose by Subdomain 


= Services must be cohesive. A service should implement a 
small set of strongly related functions. 


= Services must be loosely coupled - each service as an API SubDomains 


that encapsulates its implementation. 


= "Decompose by Subdomain" pattern offer: ee 
= Define services corresponding to Domain-Driven Design catalog 


(DDD) subdomains. 


= DDD refers to the application’s problem space, the business 
as the domain. A domain is consists of multiple 
subdomains. 


= Each subdomain corresponds to a different part of the 
business. 
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Domain-Driven Design (DDD) subdomains 
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Bounded Context Pattern (Domain-Driven Design) 


= DDD - Bounded Context Pattern which is one of the main 
pattern that we mainly use when decomposing 
microservices. 


Domain 


Optimal Acquisition 
Context 


= Domains are require high cooperation and have a certain 
complexity by nature are called collaborative domains. 


= DDD has 2 phases, Strategic and Tactical DDD. 


= Strategic DDD, we define the large-scale model of the system, 
defining to the business rules that allow designing loosely 
coupling units and the context map between them. 


Inventory 
(Supporting) 


Inventory Context 


a 
I'm a 


Resource 
Planning 
(Generic) 


Mapping 
Context 
(External) 


= Tactical DDD focuses on implementation and provides design 
patterns that we can use to build the software implementation. 


= Include concepts such as entity, aggregate, value object, 
repository, and domain service. 
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esign Adapt 


Bounded Context Pattern (Domain-Driven Design)-2 


= DDD domain defines its own common language and divides 
boundaries into specific, independent components. Common 
language is called ubiquitous language, and independent Lu Bang "EES wg 
units are called bounded context. 7 


Sales Context 


= DDD is solving a complex problem is to break the problem into 
smaller parts and focus on smaller problems that are relatively 
easy. \ 


= A complex domain may contain sub domains. And some of 
sub domains can combine and grouping with each other for 
common rules and responsibilities. 


= Bounded Context is the grouping of closely related scopes tha 


we can say logical boundaries. Contexts and being explicit about their interrelationships. 


= Bounded context is the logical boundary that represents the 
smaller problem particles of the complex domain that are self- 
consistent and as independent as possible. 


http://martinfowler.com/bliki/BoundedContext.html 
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DDD deals with large models by dividing them into different Bounded 


Identify Bounded Context Boundaries 
for Each Microservices 


How we can identify Bounded Context ? 
To identify bounded contexts use DDD. 


In DDD, use the Context Mapping pattern for identification of 
bounded contexts. 


With Context Mapping Pattern, we can identify the whole 
bounded contexts in the application and with their logical 
boundaries. 


The solution is using Context Mapping. 


The Context Map is a way to define logical boundaries 


between domains. DDD deals with large models by dividing them into different Bounded 


Contexts and being explicit about their interrelationships. 


http://martinfowler.com/bliki/BoundedContext.html 
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Identify Bounded Context Boundaries 
for Each Microservices-2 


= Identify the Bounded Contexts by talking to the domain 
experts and using some clues. 


= Once defined the Bounded Contexts, iterate design, those are 
not immutable. 


Customers Orders 


= Reshape your Bounded Contexts by talking to the domain 
experts and consider refactoring's with the changing 
conditions. 


= Its crucial to discuss with domain experts to defining domains 


and sub domains. Payment 


Shopping Cart 


= Evaluate Bounded Context with the domain experts will help 
you identify to microservices. 


same data but naming differently due to domain experts areas. L--== =I IIIT eo eee eee eee 


= Sub domains inside of the Bounded Context are representing 


= Should discuss several domain experts for their expertise 
areas. 
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A Bounded Context == A Microservice ? 


= No right answer to this question under all circumstances. 


= Bounded Context can create more than one Microservice. Identify Bounded Context Boundaries for Each Microservices 


= Decision to be made based on the microservice's need for 
scalability and independence. 


Orders 


Customers 


= Since Bounded Context defines the boundaries of the domain, 
a Microservice determines the technical and organizational 
boundaries. 


Companies|{ Account 


= Similar to Microservices, Bounded Contexts are 


| = P t 
autonomous and responsible by certain domain capability. ne 


Shopping Cart 


= Context Mapping and the Bounded Context pattern are 
good approaches for identifying microservices. 
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Using Domain Analysis to Model Microservices 


= Microservices should be designed by business capabilities 


and should have loose coupling and autonomous services. 


= We can change a particular microservices without affecting 
other services. Each service can be change independently. 


= Domain-driven design (DDD) provides a set of methodology 
that we can follow the principles and create a well-designed 
microservices. 


= Follow DDD-Bounded Context which following Context 
Mapping Pattern and decompose by sub domain models 
patterns. 


esign Adapt 


DDD deals with large models by dividing them into different Bounded 
Contexts and being explicit about their interrelationships. 


http://martinfowler.com/bliki/BoundedContext.html 
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Checklist After Decompose Microservices 


= WMicroservice should do "one thing" 
No certain process that will produce the right design. But Each service should has a single responsibility. 
Think deeply about our business domain, bounded contexts and sub domain models patterns. 


= WMicroservice size should not too big and not too small 
Start from a carefully designed domain model and group small sub models with obeying this rule. Each 
service is small enough that it can be built by a small team working independently. 


= Avoid Chatty Communication 
When you splitting functionality into two services, if those services becomes overly chatty 
communications, then its good to combine them into 1 service. 


= No Locking Dependencies 
If your services has inter-service dependencies more than 2 or 3, and if those are required to move and 
deploy together that means there are pain points of your design and its good to re-think again. 


= It should always be possible to deploy a microservice without re-deploying any other services. Services 
should not be tightly coupled, and can evolve independently. 
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Microservices Decomposition Path 


E-Commerce Identify 
Bounded Decompose Kee i 
Domain e Microservice 
' Contexts Strategies 
Analysis Boundaries 


Passes eeseeeanuy 
= em em em em em em em em em wn wll 
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Understand E-Commerce Domain 


= Our Domain: E-Commerce 


= Understand Domain and Decompose small pieces 
= Use Cases 
= Functional Requirements 


Identify steps; 

= Requirements and Modelling 

= Identify User Stories 

= Identify the Nouns in the user stories 


= Identify the Verbs in the user stories 


TRACK YOUR ORDER LOCATE STORE 


HURRY UP! 


uPhone X 
ITS 29% OFF 


GET IT NOW 
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Understand E-Commerce Domain: Functional Requirements 


= List products 
= Filter products as per brand and categories 
= Put products into the shopping cart 


= Apply coupon for discounts and see the total cost 
all for all of the items in shopping cart 


= Checkout the shopping cart and create an order 


= List my old orders and order items history 


HURRY UP! 


uPhone X 
ITS 29% OFF 


GET IT NOW 


Mehmet Ozkaya 


209 


Understand E-Commerce Domain: User Stories (Use Cases) 


= As a user | want to list products 


= As a user | want to filter products as per brand and 
categories 


= As a user | want to put products into the shopping cart so 
that | can check out quickly later 


= As a user | want to apply coupon for discounts and see the 
total cost all for all of the items that are in my cart 


= As a user | want to checkout the shopping cart and create HURRY UP! 
an order uPhone X 

= As a user | want to list my old orders and order items TS 29% OFF 
history Ee 


= As a user | want to login the system as a user and the 
system should remember my shopping cart items 
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Analysis E-Commerce Domain - Nouns and Verbs 


= As a user | want to list products 

= As a user | want to be able to filter products as per brand and categories 

= As a user | want to see the supplier of product in the product detail screen with all characteristics of product 

= As a user | want to be able to put products that | want to purchase in to the shopping cart so | can check out 
= As a user | want to see the total cost all for all of the items that are in my cart so that | see if | can afford to buy 
= As a user | want to see the total cost of each item in the shopping cart so that | can re-check the price for items 
= As a user | want to be able to specify the address of where all of the products are going to be sent to 

= As a user | want to be able to add a note to the delivery address so that | can provide special instructions 

= As a user | want to be able to specify my credit card information during check out so | can pay for the items 

= As a user | want system to tell me how many items are in stock so that | Know how many items | can purchase 
= As a user | want to receive order confirmation email with order number so that | have proof of purchase 

= As a user | want to list my old orders and order items history 


= As a user | want to login the system as a user and the system should remember my shopping cart items 
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Analysis E-Commerce Domain - Nouns 


= Customer 


= Order T 


= Order Details EIT 
pping order confirmation email created by 


contains 
e Shopping Cart gets item tax total by 
m Shopping Cart Items e O email sent by 


a 


calculates 


invoice sent to Invoice Address 


items sent to 


Delivery Address 


Credit Card 


= Product 


calculates 


= User 
= Address 


by customer 


E Brand by seller 


` Category 
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Analysis E-Commerce Domain - Verbs 


Customer place 


uses 


List products applying to paging 

Filter products by brand, category and supplier 
See product all information in the details screen 
Put products in to the shopping cart 

See total cost for all of the items 

See total cost for each item 

Checkout order with purchase steps 

Specify delivery address 

Specify delivery note for delivery address 
Specify credit card information 

Pay for the items 

Tell me how many items are in stock 

Receive order confirmation email 


List the order and details history 


invoice sent to Invoice Address 


items sent to 


Delivery Address 


Credit Card 


order confirmation email created by 


Email Generator 


email sent by 


Email Dispatcher 


calculates 


Business Tax 


by seller 


calculates 


by customer 
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Login the system and remember the shopping cart items 


Object Responsibility Diagram 


Specify invoice address 


Place Order 
Get order summary) 


Delivery Address 


Shopping Cart Add delivery note 
Credit Card Specify delivery address 


Add items e z 3 > 
et total price Specify credit card information 


Get total tax 
erify checkout Email Generator 


Generate Order Email 


Email Dispatcher 


Send Email 


Get quantity 
Get price 
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2 Main Use Case of Our E-Commerce Application 


ap oe mm we wm oe e Oo e, wm em om emm wm emm oe oe EE EE E EE 
Sync Case Async Case 


Add to basket Place Order 


order placed 
get payment 
decrease stock 


1. Get latest discount R 
A 
4. send shipment 
5 
6 


from discount 
2. Add basket 


generate bill 
. update order table 


ee ee 
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Identifying and Decomposing Microservices for E-Commerce Domain 


Order Transactional Microservices 


| Payment | 


Main Microservices 


Notification 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services 
by scalability 


The Scale Cube 


Microservices 
Decomposition 
Pattern 


Decompose by 
Business Capability 


Decompose by 
Subdomain 


Bounded 
Context Pattern 


Context Mapping 
pattern 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 


Mehmet Ozkaya 


217 


all 
By 
5 
oS 
T 
D 
= 
r= 
O 
< 
< 
o 
q) 
2 
> 
E 
SÉ 
o 
O 
E 
2 
= 
e 
D 
o 
qd) 
el 


O8) QÐ QÐ 8 


Mieroserviees 
| Shopping 
Cart 
Aà Ordering 


\ 


I ene á- á- á- es emm = = =- = = em em em em em e 


A 


eerie 
Client Apps 
$ 
© 


Mehmet Ozkaya 218 


Adapt: Microservices Architecture 
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e Nei — Asp.net 

e JS — NodeJS 

e Python — Django, Flask 
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e Postgres — Relational 


, SQL Server — Relational 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservices Architecture 


Main Considerations 
Decomposition — 
Breaking Down 
Services 
Communications 
Data Management 


Client App 
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Problem: Direct Client-to-Service Communication l = 


Problems 

e Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app. NoSQL 
Document 


Solutions NoSQL 
e Well-defined API Design Key-Value 
, Microservices Communication Patterns Gë 
Les Relational 
Relational 
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Microservices 
Communications — The 
Basics 


Microservices Communication Types - Synchronous or Asynchronous Communication 
RESTful API design for Microservices 

GraphQL API flexible structured relational data for Microservices 

gRPC high performance communication between internal Microservices 


WebSocket API Real-time two-way communications 
Mehmet Ozkaya 
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Architecture Design — Vertical Considerations 


Modular : : 
pene Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Problem: Direct Client-to-Service Communication 


Problems 

« Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app. 


Solutions 
e Well-defined API Design 
, Microservices Communication Patterns 


Steps 

e Microservice Communications and Types 

, Well-defined RESTful API Design for services 

, Microservices Communication Patterns (API 
Gateway, BFF, Publish/Subscribe..) 


NoSQL 
Document 


NoSQL 
Key-Value 


© Relational 


Relational 
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Communications Between Monolithic to Microservices 


= The communication in Monolithic applications are inter- 
process communication. 


= Working on single process that invoke one to another by 
using method calls. Create class and call the method inside 
of target module. All running the same process. 


Sesugseeee2re4 


= The biggest challenge when moving to microservices- 
based application is changing the communication a Dé 
mechanism. i 


Client 
= Microservices are distributed and microservices 
communicate with each other by inter-service 
communication on network level. 


rrr eeese2 2 


= Services must interact using an inter-service 
communication protocols like HTTP, gRPC or message 
brokers AMQP protocol. 
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Microservices Communications 


= Isolate the business into microservices as much as possible. 


= Use asynchronous communication between the internal 
microservices as much as possible. 


= Create well-defined APIs for inter-service communications. 


= Monolithic inter-process method calls becomes well-defined 
APIs into Microservices. a 


= Group some operations and expose aggregated APIs that 
cover several calls from multiple sources. Client 


= Smart endpoints and dumb pipes: microservices loosely 
coupling and expose endpoints with RESTFul APIs in order to 
provide end-to-end use cases. 


= Microservices communication types: 
= Synchronous communications: Request/Response 
= Asynchronous communications: Message broker event buses 
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Microservices Synchronous Communication 


= Synchronous communication is using HTTP or gRPC 
protocol for returning synchronous response. 


= The client sends a request and waits for a response from 


the service. 
= The client code block their thread, until the response reach( 
from the server. Client 


Http / gRPC 
= The synchronous communication protocols can be HTTP or se ail iar 


HTTPS. 


= The client sends a request with using http protocols and 
waits for a response from the service. 


rrr em eee em e e eee eee = wm wm em om wm = 


= The client call the server and block client their operations. 


= The client code will continue its task when it receives the 
HTTP server response. 
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Microservices Asynchronous Communication 


= The client sends a request but it doesn't wait for a 
response from the service. 


= The client should not have blocked a thread while waiting 
for a response. 


= Using AMQP protocols, the client sends the message with 


= AMQP (Advanced Message Queuing Protocol) A ! 
using message broker systems like Kafka and RabbitMQ ` client ! 


queue. 
= The message producer does not wait for a response. 


= Message consume from the subscriber systems in async 
way, and no one waiting for response suddenly. 


= Asynchronous communication also divided by 2: 
= one-to-one(queue) 
= one-to-many (topic) 
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Microservices Asynchronous Communication-2 


= one-to-one(queue) implementation dae E OCS ; 
one-to-one(queue) implementation there is a single 
producer and single receiver. ! 
= Command Patterns offers to receive one queue object and ( sn Y {aveue( | SEN g 
after that execute the command with incoming message. 
This process restarts with receiving new command qUGUG ere EE ee S 
item. 


= one-to-many (topic) implementation 
In one-to-many (topic) implementation has Multiple 
receivers. Each request can be processed by zero to 


P 
I 
I 
H 
H 
a 
D 
H 
H 
Itipl e 1 
multiple receivers. a | 1 
i i i Leecl. men? 
= Event-bus or message broker system is publishing events ; : 
I 
H 
I 
U 


between multiple microservices and communication provide 
with subscribing these events in an async way. 


= Publish/subscribe mechanism used in Event-driven aaa adele a e 
microservices architecture. 
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Microservices Communication Styles 


= Request/response communication with HTTP and REST 
Protocol (extends gRPC and GraphQL) 


= Push and real-time communication based on HTTP, 
WebSocket Protocol Microservices Http Communication 


= Pull communication based on HTTP and AMQP (short SS 
polling - long polling) eee KS 
e e e . R : i 200 OK 
= Event-Driven communication with Publish/Subscribe A- pe RoC 
req/res g 
Model ! 201 Created y 
i | HTTP POS í 


Mehmet Ozkaya 232 


Request/response communication 


= When using synchronous request/response-based 
communication mechanism, use HTTP and REST protocols 
that are the most common protocols. 


Microservices Http Communication 


= Expose APIs from our microservices using the HTTP and 


REST protocols. ! (e es 
= REST HTTP calls using HTTP verbs like GET, POST, and ! 300 OK E 
PUT. anc gRPC 
! 201 Created ? 
= |f our communication held between internal microservices, use Client ee E 
gRPC protocol communication mechanisms to provide high Ty 
performance and low latency. 


= Use GraphQL instead of the REST APIs when performing 
Request/response communication. 


= With GraphQL, we can define the structure of the data 
required and get 1 response in 1 request with more flexibility 
and efficiency way to get whole data. 
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Push/pull communication 


= Push and real-time communication based on HTTP, WebSocket Protocol 
Use case about real-time and one-to-many communication like chat application, use Push Model with 
HTTP and WebSocket Protocols. 


= Build real-time two-way communication applications, such as chat apps and streaming dashboards like 
the score of a sports game, with WebSocket APIs. 


= The client and the server can both send messages to each other at any time. Backend servers can easily 
push data to connected users and devices. 


= Pull communication based on HTTP and AMQP (short polling - long polling) 
Also called "Polling" and it's basically the same as refreshing your mail inbox every 5 minutes to check for 
new mail. It is a call and ask model. 


= This model is become a waste of bandwidth if there are no new messages and responses comes from the 
server. 


= Opening and closing connections is expensive. And we can say that this model doesn't scale well. 


= Typically have limits like on Twitter on how often they allow you to call their API. 
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Event-Driven communication with Publish/Subscribe 


= Microservices don’t call each other, instead, they created 
events and consume events from message broker systems 
in an async way. 


= AMQP (Advanced Message Queuing Protocol) 
= Publish/Subscribe pattern with events A 


= Using AMQP protocols, the client sends the message with 
using message broker systems like Kafka and RabbitMQ ciient | 
queue. 


= The producer service of the events doesn't know about its 
consumer services. the consumers also don't necessarily 
know about the producer. Lanem an wenewnncnennne annem ass wnw en nensnnnn= 


= Decouple services and build loosely coupled microservices. 


= No clear central place or orchestrator, This increase 
complexity of architecture. 
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Microservices Synchronous Communications 
and Best Practices 


= The client sends a request with using http protocols and 
waits for a response from the service. 


= The synchronous communication protocols can be HTTP or Wee i 
HTTPS. 


= Request/response communication with HTTP and REST B 
Protocol (extends gRPC and GraphQL) 


= REST HTTP APIs when exposing from microservices 


Client 


Http / gRPC 
Request/Responses 4 
= gRPC APIs when communicate internal microservices 

= GraphQL APIs when structured flexible data in microservices 


= WebSocket APIs when real-time bi-directional communicatior 


errr mm em es ws ew ee eee mm en em e wem em wm wm wm — 


= How can we design and exposing APIs with HTTP protocols 
for our microservices ? 
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Problem: Direct Client-to-Service Communication 


Problems 

« Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app. 


Solutions 
e Well-defined API Design 
, Microservices Communication Patterns 


Steps 

e Microservice Communications and Types 

e Well-defined RESTful API Design for services 

e Microservices Communication Patterns (API 
Gateway, BFF, Publish/Subscribe..) 


NoSQL 
Document 


NoSQL 
Key-Value 


© Relational 


Relational 
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Designing HTTP based RESTful APIs for Microservices 


= When making request/response communication, we should 
use REST when designing our APIs. Its also called Restful 
d 0 a ai in i Canna itech anise 


= REST approach is following the HTTP protocol, and 
implementing HTTP verbs like GET, POST, and PUT. 


= REST is the most commonly used architectural éi 
` e tt 4 
communication approach when creating APIs for our ( Vente EN 

microservices. 


Client 


U 
= Java and Sprint Boot framework - 
= C# with ASP.NET Core Web API 
= Python with Flask Web API framework 1 


| 


Os cscs esas ai dV ce EN 


= How to design our APIs for microservices ? 
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Designing HTTP based RESTful APIs for Microservice2 C 


Problem Learn pt 


Well-defined API design is very important in a microservices architecture, communication happens API calls. 


Designed APIs should be efficient and not to be chatty communications. APIs must have well-defined 
documented and versioning. 


There are 2 type APIs sync communication in microservices: 
= Public APIs: API calls from the client apps. 
= Backend APIs: inter-service communication between backend services. 


Public APIs 

Use RESTful APIs over HTTP protocol. RESTful APIs use A- 
JSON payloads for request-response, that easy to check 
payloads and easy agreement with clients. 


Backend APIs 

Inter-service communication can result in a lot of network 
traffic. serialization speed and payload size become more 
important. Using gRPC is mandatory for increase network 
performance. 


Client 


WE EE 
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Comparison with REST and gRPC 


= REST is using HTTP protocol, and request-response 
structured JSON objects. 


= API interfaces design based on HTTP verbs like GET-PUT- 
POST and DELETE. 


Microservices Http Communication 


= gRPC is basically Remote Procedure Call, that basically 


E 
l 
| 
i 
) 
invoke external system method over the binary network vat OO dem 
protocols. rd sion E gRPC 
l ' 201 Created 
= Payloads are not readable but its faster that REST APIS. client HTTP POS} BS dës, 
3 ES 
| 
L 


= 2 Main Approaches for Public and Backend APIs: 
= RESTful API Design over HTTP using JSON 
= QRPC binary protocol API Design 


Os cscs esas ai dV ce EN 
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RESTful API design for Microservices 


RESTful services are widely used in modern Web architectures. Mobile 
SE , , , , Applications Cloud-Based 
It is lightweight, extensible and simple easy develop services. Services 
What is REST ? || Be Partner 
Applications 


REST (Representational State Transfer) is a service structure that Bac 
enables easy and fast communication between client and server. 

Roy Fielding introduced and developed REST in his doctoral CH 
thesis in 2000. 


REST allows applications to communicate with each other by z 


i 
d 


Cloud 


Resources 
= Cacheable Ss 


= Client-Server Application Data 
» Layered System Servers 
= Code on Demand 


carrying JSON data between the client and server. 


Characteristics of the REST Architecture: i; 
egacy 


= Stateless Applications 
= Uniform Interface 
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What is RESTFul APIs? 


= Web services that use REST architecture are called RESTful Mobile 
services. Applications Cloud-Based 


Services 
= RESTful systems communicates over HTTP protocol with HTTP GA E d Piah 
Applications 


methods used by Web Browsers to transfer pages. Applications 


= Richardson Maturity Model 
Leonard Richardson proposed the Richardson Maturity Model for CH 
web APIs: age? 


= Level 0: Define one URI, and all operations are POST requests to 
this URI. 


= Level 1: Create separate URIs for individual resources. 


Legacy 
= Level 2: Use HTTP methods to define operations on resources. Applications 


= Resources 


Application Data 
Servers 


= Level 3: Use hypermedia 
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HTTP Methods 


HTTP Methods 


TTP Methods i 
o kum 1 
ee ker 1 
CECR 
"ns kass | 


DELETE Delete the object at the location E 


PATCH Update single piece of data g 
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RESTful API design for Single Microservice 


= Focus on the business entities that we expose APIs for our application. 
Organize our resources according to business entities and expose via APIs. 


= Design RESTful APIs for single Product Microservices. 


= Rule1- REST APIs are designed around "resources" 
The best practice is the resource URIs should be based on nouns = the 


resource and not verbs. REST API Url: https://e-shop.com/products | RESTful API design for Single Microservice | 

= https://e-shop.com/products -- Correct 1 HTTP GET CO 

=  https://e-shop.com/create-product -- Wrong — ZS rates Ze 

= Rule2- Every Resource has an identifier oe i 
Unique identifiers for that resource. REST API URL becomes fora Client i -------------------------- 4 


particular product: https://e-shop.com/products/4 
= This will return single product which id = 4. 


= API frameworks route requests based on parameterized URI paths, so we 
can define a route for the path like /products/{id}. 
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RESTful API design for Single Microservice-2 


= Rule3- REST APIs are using JSON 
REST API url has GET request, then it will return this response body as a JSON response: 


= {"productld":1,"name":"IPhone", "price":44.90,"category":"Electronics"} 
= Rule4- REST APIs perform operations on Resources with HTTP verbs: 


REST APIs built on HTTP protocol and perform operations on Resources with HTTP verbs, these verbs are 
GET, POST, PUT, PATCH, and DELETE. 


= When creating a product, we send HTTP POST request with contains product detail informations and return 
back to HTTP response that including 200 OK success response. 


= Response: 201 Created 1 200 OK 


m THEGUC ST i i: EE ae Sw wt e 1 
| RESTful API design for Single Microservice , 

= HTTP: POST ' 
= Url: https://e-shop.com/products HTTP GET 
= Body: {"productid":1,"name":"|Phone"} /products 
i 

t 

i 


Client vu 4 
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RESTful API design for E-Commerce Microservices 


= RESTful API design for E-Commerce Microservices: Customer, Order and Product resources. 
= How should we design Rest API when you required to get customer orders ? 
= URL: https://e-shop.com/customers/6/orders 


= | want to retrieve products into order number 22 which ordered by customer 6: 
= URL: https://e-shop.com/customers/6/orders/22/products --WRONG 


l 
I 
= This level of complexity can be difficult to maintain. ! 
t 
: 
U 


= Instead, we should keep URIs relatively simple. 


http D 
= Resource URIs should not be more complex d EE 


than "collection/item/collection" path. Client 


= First we should get Customer orders with this API: 
= URL: https://e-shop.com/customers/6/orders 

= After that we should locate the Order no 22 and get all products: 
= URL: https://e-shop.com/orders/22/products 


ME ee EE ERE E E 


Poena 
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RESTful API design with HTTP Methods 


Create new Retrieve all Update all 
/customers 
customer customers customers 


Update data for 
Retrieve data , 
/customers/1 N/A customer 1 if 
for customer 1 BS 


Create new orde fie lata Update all order 


/customers/1/orders orders for 
for customer 1 for customer 1 
customer 1 


DELETE 


Remove all 
customers 


Remove 
customer 1 


Remove all 
orders 
customer 1 
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RESTful API design for Relational Data 


= Microservices don't share the same code base and don't share data stores. They communicate 
through APIs for data operations. 


= Shopping Cart service requests information about a customer from the Customer service. 


= Customer service retrieve data with using Repository classes and return Customer entity model 
as a JSON object in an HTTP response. 


LEET 
- Microservices RESTful API Design 
t 
‘ 
f Shopping 
i Cart GET /api/customer/1—X 
il 


Client {i Customer entity 
i JSON object 


Lease ee eee eee ee en e e e e e el 
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API versioning in Microservices RESTful APIs 


= If an API changes, there may broke some communications which depending 
on that API from other microservices. 


= Services may required to add new features or bug fixes that require 
changing an existing API. 


= API changes should be backward compatible and not break any 
communications. 


= Best practice for the roll-out or canary deployments on Kubernetes. 


= If your microservices has one more pods, new version of API deployments 
handle one by one and if there is a problem its easy to rollback to previous 
version. 


= Microservices should supports two versions with following backward 
compatible. 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 


HTTP Based RESTful 
API design 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Microservices 


| 
i 
! HTTP GET 
/ duct & 
products AJ Customer DE, 
: 200 Qk 
| 
) 


e Shopping © 
fa Ën J 
i Ce 
8 Gerten = 
i ; A. Ordering > 
Içarts/{id}/checkoųt 
p ecko e 
L 


ahr 
ee A 
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Microservices Resource one REST APIs 
Methods 
HTTP GET GET/customers /customers 
HTTP POST |GET /customers/{id} 
Customer /customers 


HTTP POST /customers 
DELETE DELETE /customers/{id} 
—_— 


HTTP GET 
HTTP POST 


GET /products 
ET /products/{id} 

POST /products 

DELETE /products/{id} 


GET /carts 

GET /carts/{id} 
POST /carts/{id}/checkout 
DELETE /carts/{id} 


HTTP GET 
HTTP POST 
HTTP 
DELETE 


HTTP GET 
HTTP POST 
SS HTTP SEN 


GET /orders 
GET /orders/{id} 
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Problem Adapt 


Evaluate: Microservice Architecture with RESTful APIs Ta- 


"mm emm æ em e Åe mmm = oe | , ~ewwmoeeoeoaeoesseoen eu ooenueneeen20e0n02—7™ 
Benefits Client Apps | i Microservices 
ı |  HTTPGET 
e Request can simply sent using browsers. Ai dok 
l 
, HTTP protocol t i 2009 Customer 
I 
Jä 
I 


I 

I 

I 

U 

U 

I 

i 

« HTTP GET has organic caching options 
e JSON representative request-responses 
? 

i 


Drawbacks 
e Send multiple request to get relational data 
e Chatty communication when enriching data 


Sh i 
Sie Lk 
; Ordering e 


Microservices | Resource ed REST APIs 
Methods 
HTTP GET GET /customers /customers 
HTTP POST |GET /customers/{id} 
Customer /customers 
HTTP POST /customers 
DELETE DELETE ELETE /customersi{id} ` 
HTTP GET |GET /products 
IHTTP POST ET /products/{id} 
[products TTP POST /products 

DELETE DELETE -LETE /products/{id} _ 
HTTP GET |GET /carts 
HTTP POST |GET /carts/{id} 

S 

hopping Cart | Jeans ` Jee POST /carts/{id}/checkout 

DELETE DELETE ELETE /carts/{id} ` 


= lorders E e GET /orders 
i GET /orders/{id} 


HTTP 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Multiple Request for Retrieve Relational Data | =a 


Problems 
e Business teams want to see relational data on 


screen. N+1 problem. 

e Customer — Orders — Products 

e REST: /customer/3/orders/4/products ? 

e How we can get Products from Order X for 
Customer Y ? 

e Chatty Calls for enriching data 


Solutions 

e GraphQL API Design 

e Structural relational data with querying 
GraphQL API 


| Problem E Learn H Design H Adapt 


Sh i 
Sie Lk 
; Ordering e 


Microservices | Resource ed REST APIs 
Methods 
HTTP GET GET /customers /customers 
HTTP POST |GET /customers/{id} 
Customer /customers 
HTTP POST /customers 
DELETE DELETE ELETE /customersi{id} ` 
HTTP GET |GET /products 
IHTTP POST ET /products/{id} 
[products TTP POST /products 

DELETE DELETE LETE /products/{id} _ 
HTTP GET |GET /carts 
HTTP POST |GET /carts/{id} 

S C I 

hopping Cart carts lutte POST /carts/{id}/checkout 

DELETE DELETE ELETE /carts/{id} ` 


omna lorders E e GET /orders 
. GET /orders/{id} 


HTTP 
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Client Apps | Microservices 
ı | HTTP GET 
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GraphQL: A query language for APIs 


= GraphQL is a query and manipulation language for APIs anda 
runtime for fulfilling queries with your existing data. 


= It was developed internally b Facebook in 2012 before being publicly 
released in 2015. 


= It allows clients to define the structure of the data required, and the 
same structure of the data is returned from the server. 

= |t provides a complete and understandable description of the data G ra L N Q | 
in our API, clients requests what they need, easier to evolve APIs 
over time, has powerful developer tools. 


= It provides a flexible syntax to describe data requirements and 
interactions. 


= It provides to access many sources in a single request, reducing the 
number of multiple network calls. 


= Developers to ask for exactly what is needed and get back 
predictable results. 
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Characteristics of GraphQL 


= Ask for what you need, get exactly that 
Send a GraphQL query to your API and get exactly what you need. 
GraphQL queries always return predictable results. 


= Get many resources in a single request 
GraphQL queries can access the properties of one resource and also 
relations of particular resource references between them. 


= GraphQL APIs get all the data your applications needs in a single G ra N Q | 
request. D 


= Evolve APIs without versions 
As you know that REST APIs requires versions when change your 
resource properties. We can add new fields and types to GraphQL API 
without impacting existing queries. 


=" By using a single evolving version, GraphQL APIs give apps 
continuous access to new features. 
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Core Concepts of GraphQL oe Hee Hm 
schemas, Queries, Mutations and Resolvers ee 


= Developers can use GraphQL in order to create a schema, which 
describes all the possible data that clients can query on it. 


= GraphQL schema is made up of object types, that define which kind 
of object you can request and which fields it has. 


= Client can send queries, GraphQL validates the queries against the 
schema then executes the validated queries. 

= Resolver is a function that attaches to fields in a schema. During G ra L N Q | 
execution, the resolver is called to produce the value. 


= Mutation is a GraphQL Operation that allows you to insert new data 
or modify the existing data on the server-side. 
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Example of GraphQL Query 


= Simply send a single query to the GraphQL server that includes the concrete data requirements. The 


server then responds with a JSON object. 


= See example Order and Order Products list as below: 


POST Request: 
{ 


orders { 
id 
productsList { 
product { 
name 
price 
} 
quantity 
} 


totalAmount 


Response: 


"data": { 
"orders": [ 
{ 
"id": 1, 
“productsList”": [ 


"product": { 
"name": "orange", 
"price": 1.5 


}, 
"quantity": 100 


k 
“"totalAmount": 150 
} 
] 
} 


} 
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Advantages of GraphQL 


= GraphQL is fast 
GraphQL is way faster than other communication APIs like REST APIs 
because it reduce to multiple calls to get data and provides to query by 
choosing only the specific fields. 


= Single Request 


GraphQL get all the data your applications needs in a single request. 
Clients get what they request with no over-fetching. 
= Strongly typed G ra L a Q L 


In GraphQL we describe data before query it. Strongly defined data 
types reduce miscommunication. 


= Hierarchical Structure 
GraphQL provides a hierarchical structure where relationships between 
objects are defined in a graphical structure. 


= Evolve API 
GraphQL allows an application API to evolve without breaking existing 
queries. 
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Disadvantages of GraphQL 


= GraphQL Query Complexity 
When access multiple fields in one query, it may requests too many 
nested fields data at a single time that could cause performance 
problems. Consider maximum query depths, query complexity. 


=" GraphQL Caching 


More complicated to implement a simple cache with GraphQL. 
Complex because each query can be different, even though it 
operates on the same entity. G ra L N Q | 
= GraphQL Rate Limiting 

In REST API, we can simply specify that we allow only the specific 


amount of requests in specific time, but In GraphQL, it is difficult to 
specify this type of statement. 
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REST vs GraphQL APIs 


= REST has become the de-facto standard for designing web APIs, 
However, REST APIs are too inflexible to rapidly changing 
requirements of the clients. 


= GraphQL was developed for more flexibility and efficiency that solves 
many of the shortcomings and inefficiency calls. 


= REST has the advantages of being a popular API, and also it is easy 
to understand, as well as scalable. 


= GraphQL is more complex than REST, main drawbacks are error 
reporting, caching, and N+1. 


= GraphQL solves the under-fetching problem that REST can't fetch 
hierarchical data at once. 


= GraphQL and REST are two API styles that have a different approach 
when dealing with the transfer of data over HTTP protocols. 
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REST vs GraphQL APIs 


REST APIs 
e Easy to understand 


e Defacto standard Popular APIs 
for designing web APIs 


e Provide better scalability 


e Built-in caching that minimizes 
multiple trips 


Drawbacks: 


e Over-fetching and under-fetching 
requests are hard to implement 


and required multiple calls. 


GraphQL APIs 


Solving the over and under- dt 
fetching problem 


More flexible with Schema and API 
Type System 


Quick response time 


Protocol agnostic 


Drawbacks: 


Complexity and caching 
problems. 
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Fetching Data with REST and GraphQL 


= Blogging application, an application needs to display screen, 


= "posts" of the specific "user" and the last 3 "follower" names at the 
same screen. dt 
REST ) 
= users -> posts, users -> followers API 


= How can we fetch this data with REST and GraphQL ? 
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Fetching Data with REST APIs 


= REST API, we have to call multiple endpoints to a 
fetch data. = ES S “ — 
1. /users/<id> endpoint to fetch the initial user data. Q D ECH — 
2. /users/<id>/posts endpoint that returns all the AUEREN i 
posts for a user. ! 


3. /users/<id>/followers that returns a list of 
followers per user. 


= a 
(2) = HTTP GET Ch /users/<id>/posts CH 
= With REST, have to make 3 requests to different E GN isers/<id>/folton emm 
endpoints to fetch the required data. “eontent": sLorem ipsum än 
“comments”: [ .. ], 
, S S ‘ DI 
= is over-fetching since the endpoints return 
additional information that’s not required. SE 
= eas 26, 1982” KS 
G) ) ir ay”: uly P 
E K Km 
z HTTP GET © a /users/<id>/followers 


https://www.howtographql.com/basics/1-graphql-is-the-better-rest/ 
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Fetching Data with GraphQL APIs 


= GraphQL API, simply send 1 single query to 


: { 
the GraphQL server that includes the concrete Muser(id: “er3tga39trjw") { 
` name 
data requirements. posts { 
1 ES 
e Then the server responds with a JSON object Eege 3) { 
` ` ` name 
that includes required fields. } 
} 
= Using GraphQL, the client can specify exactly = 
the data it needs in a query. HTTP POST CH 
= The structure of the server’s response follows 0 ` adata”: { 
e . b “User”: 
precisely the nested structure defined in the eier “Hane: 
“ ts”: 
query. e “Learn GraphQL today” } 


], 
“followers”: [ 
{ name: “John” }, 
{ name: “Alice” }, 
{ name: “Sarah” }, 
] 
} 
} 
} 


https://www.howtographql.com/basics/1-graphql-is-the-better-rest/ 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 


HTTP Based RESTful 
API design 


GraphQL API design 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 


Mehmet Ozkaya 


267 


r 1 
Client Apps ! 


Microservices 
A d Customer > (DB, 
A 


7 HTTP POST 


Query gë 
Customer -> Orders - DE, 


> ShoppingCart -> 


Products -> ` ` 
Discounts Shopping ` E 
i Cart DE, 
| Ordering Le 


SL 
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Evaluate: Microservice Architecture with GraphQL APIs 


Benefits 

e Solving the over and under-fetching problem 
e More flexible with schema and type system 
e Quick response time 

e Protocol agnostic 


Drawbacks 
e Increase complexity 
« Caching problems 


r 4 
Client Apps 


Q i 


Microservices 


aoe 


HTTP POST 


Query Q 
Customer -> Orders - DB) 
> ShoppingCart -> 

Products -> 

Discounts Shanna 
"e 
o 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 


Mehmet Ozkaya 270 


Designing Sync APIs for Microservices 


= There are 2 type APIs sync communication in microservices: 
= Public APIs: API calls from the client apps. 
= Backend APIs: inter-service communication between backend 


services. j 
= Public APIs 
Use RESTful APIs over HTTP protocol. RESTful APIs use A- http 2 
JSON payloads for request-response, that easy to check DS 
payloads and easy agreement with clients. Client 


| 


U 

' 

t 

= Backend APIs 
Inter-service communication can result in a lot of network 
traffic. serialization soeed and payload size become more 
important. Using gRPC is mandatory for increase network 
performance. 


| EE ETE E E E E E A E 
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Problem: Inter-service communication makes E eel 9 H 
heavy load on network traffic 


Problems 
e Network performance issues on inter-service 
communication 


r < 
Client Apps ! 


I ? I 

i] 1! I 

i E i 

I TI I 

7 | 

e Backend Communication performance requirements ! KE 

, Real-time communication requirements g i 

, Streaming requirements - d 

R 8 

Example Use Case rt 
S k H U 

- Add Item into Shopping Cart that need to calculate " 8 , 

with up-to-date discounts Ee i 

H Kä requires ~ 

s i - performance : 

olutions A gRPC 

I I 

e gRPC APIs scalable and fast APIs i A , 

i] rt i} 

) 1! I 

I 1 | I 


« Able to develop with different technologies with RPC } 
framework See s a = 
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gRPC: High Performance Remote Procedure Calls 


= gQRPC is an open source remote procedure call (RPC) system 
developed at Google. 


= gRPC is a framework to efficiently connect services and build 
distributed systems. 


= It is focused on high performance and uses the HTTP/2 protocol to 


transport binary messages. a 
= Itis relies on the Protocol Buffers language to define service contracts. 


= Protocol Buffers (Protobuf), allow to define the interface to be used in 
service to service communication regardless of the programming 
language. 


= It generates cross-platform client and server bindings for many 
languages. 


= Most common usage scenarios include connecting services in 
microservices style architecture. 
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gRPC: High Performance Remote Procedure Calls 


= gRPC framework allows developers to create services that can 
communicate with each other efficiently and independently with their 
preferred programming language. 


= Once you define a contract with Protobuf, this contract used by each 
service to automatically generate the code that sets up the 


communication infrastructure. ee 
= This feature simplifies the creation of service interaction and together 
with high performance, makes gRPC the ideal framework for creating 


microservices. 
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How gRPC works ? 


= RPC is a form of Client-Server Communication that 
uses a function call rather than a usual HTTP call. 


= In GRPC, client application can directly call a method on 
a server application on a different machine like a local 
object. 


= QRPC is based on the idea of defining a service and 
methods, and these can be called remotely with their 
parameters and return types. 


gRPC Server Ruby Client 


= On the server side, the server implements this interface 


i med 
and runs a gRPC server to handle client calls. Bee 


‘or 
8 Response(s) 


= On the client side, the client has a stub that provides the 
same methods as the server. 


Android-Java Client 


= gRPC clients and servers can work and talk to each 
other in a different of environments. 
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Main Advantages of gRPC 


= Using HTTP/2 provides 30-40% more performance. 


= gRPC uses binary serialization, provides higher 
performance and less bandwidth usage than json with 
binary serialization. 


= Supporting a widely using multi-languages and platform 
supports. 


= Open Source and the powerful community behind it. 
= Supports Bi-directional Streaming operations. 
= Support SSL/TLS usage. 


= Supports many Authentication methods. 


‘GRPG 
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When to use gRPC ? Use Cases of gRPC 


= QRPC is primarily used with backend services. 


= Synchronous backend microservice-to-microservice 
communication where an immediate sync response is required to 
continue processing. 


= Polyglot environments that need to support mixed programming 


platforms. SH 
= Low latency and high throughput communication where performance 
is critical. 


= Point-to-point real-time communication that gRPC can push 
messages in real time and requires to support for bi-directional 
streaming. 


= Network constrained environments which requires less bandwith 
usage cases, binary gRPC messages are always smaller than text- 
based JSON message. 
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Inter-service Communications 
Backend microservices require 
performance with gRPC 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 


HTTP Based RESTful 
API design 


GraphQL API design 
gRPC API Design 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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ES ae EE E, E E 
Client Apps ! 


HTTP/2 


gRPC b 
de 
| ordering 
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Benefits í Client Apps | 
e High-performance communication 
e Less bandwidth usage 

e Multi-language/platform supports 
e HTTP/2 and SSL/TLS usage 


e Supports Bi-directional Streaming operations 


Drawbacks 

« Need additional library to generate codes 
that increases complexity 

e Can't read incoming-outgoing payloads that 
is not good for client to service 
communications 


HTTP/2 


i 
gRPC © 
| 


mmm wm emm mm em wm em wm em em em e ep em wem em ep em we em = em em em em em em em om emm = 
mm emm mm em em em em em em em em em em em em em em em em em em em em em em mm em em em em em em wm wm wm sl 
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Way of Learning — The Course Flow 


Problem 


e Architecture Approaches e Fill Design Toolbox e Apply Sgftware Tools 
Patterns e Design Initial version e Application Frameworks 
Principles & Best Practices e Databases 


e Identify|Clearly 


e Microservices Communications 
e HTTP Based RESTful API design 
e GraphQL API design 
e gRPC API Design 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Chat with Support Agent 


Problems 

- Business teams request to answer Customer queries 
by chatting with Support Agents 

e Real-time communication requirements 

e Sending/receiving messages in Chat window 


Example Use Case 
e E-commerce Online Agent help customer preferences 
as per product features on website 


Solutions 
e WebSocket APIs: Build real-time two-way 
communication applications 


Mary - Support Agent 


O 


Hi there @. If you have any questions 
feel free to set up a personal demo 
here. No strings attached. 
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WebSocket API: Real-time two-way communications 


= WebSocket API is an advanced technology that user can establish 
an interactive two-way communication session between WebSocket APIs 


browser and a server. Handshake 


= Send a message to a server and receive event-based | DEE 
responses without having to poll the server for a response. 


= WebSockets is a good way to handle high-scale data transfers 
between server-client. 


= WebSocket is bidirectional, it starts with ws:// or wss:// Client | persistent Connection 

= Unlike HTTP, WebSocket provides a bidirectional protocol used l Bi-directional 
in the same client-server communication cases. Communication 

= WebSocket is a stateful protocol, connection between client and =e ES 
server stays alive until terminated by one of the parties. E 


One Side Closes Connection 


= After closing the connection by either client or server, the 
connection is terminated from both ends. Connection Closed 


Mehmet Ozkaya 284 


WebSocket API: Real-time two-way communications 
WebSocket APIs 


Handshake 


Connection Opened 


Client Persistent Connection 
Bi-directional 
Communication 


ws://example.com:8000/path/to/ws 


Open Persistent Connection 


One Side Closes Connection 


Connection Closed 
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When to use WebSocket API 


= Developing Real-time Web application 
The most usage area of WebSocket is in real-time application development 
where it is required to continuous display of data at the client end. In 
WebSocket, data is constantly pushed/forwarded to the same connection that is 
already open. 


= Real-life example of WebSocket is stock trading applications. WebSocket helps 
to data handling that is drives by the deployed backend server to the client. 


= Developing Game application 
Gaming application requires to changes on the UI with WebSockets without 
updating the page and refreshing UI. WebSocket accomplish this goal without 
disturbing the UI of the gaming app. 


= Developing Chat application 
Chat application uses WebSocket to use fixed connection when exchange the 
message between subscriber, broadcasting channels. WebSocket connection is 
used for sending/receiving messages, communication becomes easy and 
quick. 


WebSocket APIs 
Handshake 
Connection Opened 
Client Persistent Connection 
| Bi-directional 
Communication 
ws://example.com:8000/path/to/ws 
Open Persistent Connection 
One Side Closes Connection 
Connection Closed 
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Before Design — What we have in our design toolbox ? 


Architectures 


Microservices 
Architecture 


Patterns&Principles 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 


HTTP Based RESTful 
API design 


GraphQL API design 
gRPC API Design 
WebSocket API 


Non-FR 
High Scalability 
High Availability 


Millions of 
Concurrent User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 
List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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? Client Sg? 


' WebSocket Connections Between Client and Microservice 


nteractive two-way 


communication 
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Benefits 

e Full-duplex communication 

e Reduces unnecessary network traffic 

e Real-time communication 

- Persistent, Bidirectional Communication 


r 7 
' Client Apps 


Drawbacks 
e A fully HTML5-compliant web browser is Gebaier 
l interactive two-way 
required. ą communication 


e Not provide intermediary/edge caching. 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Microservices Synchronous Communications 
and Best Practices 


= The client sends a request with using http protocols and waits 
for a response from the service. 


= The synchronous communication protocols can be HTTP or Wee i 
HTTPS. 


= Request/response communication with HTTP and REST B 
Protocol (extends gRPC and GraphQL) 
= REST HTTP APIs when exposing from microservices Client 
= gRPC APIs when communicate internal microservices 


Http / gRPC 
Request/Responses 4 


= GraphQL APIs when structured flexible data in microservices 
= WebSocket APIs when real-time bi-directional communication 


Question: 


= How client applications can manage all these different 
protocols and communications inside of their applications ? 
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Problem: Direct Client-to-Service Communication l = 


Problems 

« Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app with 
all different protocols (HTTP, GraphQL, gRPC, 
WebSocket) 


NoSQL 
Document 


NoSQL 
Key-Value 


© Relational 


Relational 


Solutions 
e Well-defined API Design 
, Microservices Communication Patterns 


Steps 
, Microservice Communications and Types 
e Well-defined RESTful API Design for services Pwr rrr nnn brn nnn nnn nnn nnn nnn nnn nn nnn nnn nnn nnn 
e Microservices Communication Patterns (API 

Gateway, BFF, Publish/Subscribe..) 
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Microservices 
Communications — API 
Gateways 


API Gateway Pattern 

Gateway Routing Pattern 

Gateway Aggregation Pattern 
Gateway Offloading Pattern 
Backends for Frontends Pattern-BFF 
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Architecture Design — Vertical Considerations 


Modular : : 
pene Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Problem: Direct Client-to-Service Communication l = 


Problems 

« Direct Client-to-Service Communication 

e Cause to chatty calls from client to service 

e Hard to manage invocations from client app with 
all different protocols (HTTP, GraphQL, gRPC, 
WebSocket) 

e Increased latency and complexity on the UI side 


NoSQL 
Document 


NoSQL 
Key-Value 


© Relational 


Relational 


Solutions 
e Well-defined API Design 
, Microservices Communication Patterns 


Steps 
e Microservice Communications and Types rrr rrr nn 't----------------------ļ------------- 
, Well-defined RESTful API Design for services 
, Microservices Communication Patterns (API 

Gateway, BFF, Publish/Subscribe..) Mehmet Ozkaya 295 


Problems of Direct-to-Microservices Communication 


= Drawbacks of the direct client-to-microservices 
communications, Comparison with API Gateway and direct 
client-to-microservice communications. 


= In diagram, each microservices has to open public 
endpoint to the client applications but it has lots of 
drawbacks. 


NoSQL 
Document 


= If itis small microservice-based application, and if you 
don't have so much client applications, it could be good fit to 
use direct client-to-microservices communication. 


= When you build large and complex microservice-based 
applications, if you have dozens of microservices, and 
several client applications that need to communicate 
multiple microservices. 


Relational 


= Direct-to-microservices communication can creates major 
problems. 
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Main Reasons of Why should use API Gateway 


= Client Can't Manage Communications 
The client applications can try to handle multiple calls to microservice endpoints, 
not manageable when it comes to communicates with different protocols like http, 
GraphQL, gRPC and WebSocket. 


= Complex Client Code 
Cause to lots of requests to the backend services, create possible chatty 
communications. Increases latency and complexity on the Ul side. Becomes 
complex client code. 


I 
NoSQL H 
Document ! 
i 
D 
NoSQL } 
Key-Value 
U 


' 
© Relational i 


= Strong Coupling 
Creates coupling between the client and the backend. The client needs to know f (E HE 
how the specific microservices are decomposed. Increase the coupling between ea 
client and services and also makes it harder to maintain the client. 


= Cross-cutting Concerns 
Authentication, Authorization, Rate Limiting, SSL certifications, Logging, 
Monitoring, Load Balancing and Circuit Breaker. Implementing all these cross- 
cutting concerns for every microservice is not a good solution. 
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Main Reason why should use API Gateway ? -2 


= Protocol Exchanges 
Communication required to use different protocols like exposing HTTP Rest API 
but continue to gRPC for internal communications or exposing WebSocket 
protocol. Requests must be translate to the other protocols afterwards. 


= Async Communication Requirements 
Client application can't use async communication due to not supported AMQP 
protocols. Microservices uses async communication in order to decouple 
communication as soon as possible. Hard to implement event-driven publish- 
subscribe model. 


I 
NoSQL H 
Document ! 
i 
D 
NoSQL } 
Key-Value 
U 


' 
© Relational i 


= Payload Changes for Different Clients yi (ee 
Web, Mobile and other client applications might be required different payloads ea 
when communicating with internal services. It requires to optimize data 
responses from services tailored with client applications. 
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The Solution - API Gateway Patterns 


= Use API Gateways between client and internal 
microservices and it is a single point of entry to the 
CIIEMEGDDIICAIONS: $§é .j§é  +§é.(j}jg = qj an mean eninw nm aleimas mane 


= API Gateway sits between the client and multiple 
backend services and manage routing to internal 
microservices. 


= API Gateways can handle that Cross-cutting 
concerns like authentication, authorization, protocol 
translations, Rate Limiting, Logging, Monitoring, 
Load Balancing. 


Aemayed Led 


= 
E 


= API Gateway Patterns: 
= Gateway Routing pattern 
= Gateway Aggregation pattern 
= Gateway Offloading pattern 
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Gateway Routing pattern 


= Route requests to multiple microservices with 
exposing a single endpoint. 


= Useful when expose multiple services on a single 
endpoint and route them to internal backend 
microservices based on the request. 


= The client needs to consume several microservices, 
Gateway Routing pattern offers to create a new 
endpoint that handle the request and route this request 
for each service. 


Client 


= E-commerce application might provide services such as 
search Customers, Shopping cart, discount, and order 
history. 


= |f one of microservices are changed, the Client 
doesn't know anything and not need to change any 
code on client side, the only changes will be configuration 
routing changes. 
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Gateway Routing pattern -2 


= |t abstracts your backend microservices from the = 
client applications, with allowing to keep client codes 
simple, even backend services are changed on behind 
the API Gateway. 


= Deploy microservices APIs with blue/green or canary 
deployments with multiple API versions of same 
microservices, you can gradually shift your request to 
new API with using the Gateway Routing Pattern. 


= Gateway Routing Pattern gives you the flexibility to SR 


use different API versions routing to the requests. 


= |f new version of API has got exceptions, it can be quickly 
reverted back by making only a configuration change. 


= Use Application Layer 7 routing to route the request to 
the internal services. 
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Gateway Aggregation Pattern 


= API Gateway service that provide to aggregate multiple 
individual requests towards to internal microservices 
with exposing a single request to the client. 


= Use if client application have to invoke several different 
backend microservices to perform its logic. 


= Client applications need to make multiple calls to 
different backend microservices, this leads to chattiness 
communications and impact the performance. 


= If new service added into use cases, then client need to 
send additional request that increase the network calls 
and latency. 


= To abstract complex internal backend service 
communication from the client applications. 


= Dispatches requests to the several backend services, 
then aggregates the results and sends them back to the 


requesting client. 
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Gateway Aggregation Pattern-2 


Client 
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Gateway Offloading Pattern 


= Gateway Offloading Pattern offers to combine commonly 
used shared functionalities into a gateway proxy services. 


= Shared functionalities can application development by 


moving shared service functionality into centralized places. 


= Authentication, Authorization, Rate Limiting, SSL 
certifications, Logging, Monitoring, Load Balancing. 


= Implementing cross-cutting concerns for every 
microservice is not a good solution. 


= Gateway Offloading Pattern offers to manage all those 
Cross-cutting Concerns into API Gateways. 


= Simplify the development of microservices by removing 
the cross-cutting concerns on services to maintain 
supporting resources, allow to focus on the application 
functionality. 


Gateway Offloading Pattern 


Rate Limiting Protocol 
Circuit Breaker Conversiop 


—* Yl A 
a SSL Certificate ShoppingCart 


Client Load Geisler A 


Logging 
Monitoring 


Authenticatio 
Authorization 
| Token Management 
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Gateway Offloading Pattern -2 


Gateway Offloading Pattern 


Rate Limiting Protocol 
Circuit Breaker _ lee i 


d 
r} A 
d 
~ Gateway 2 
d 
d d 


OF d 
Client Load Balancing 4 
Logging 
Monitoring 


Authenticatio 
Authorization 
|, Token Management 


Identity 
Server 
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API Gateway Pattern 


= API Gateway is a single point of entry to the client 
applications, sits between the client and multiple backend. 


= API Gateways manage routing to internal microservices 
and able to aggreate several microservice request in 1 
response and handle cross-cutting concerns. 


= Recommended when design complex large microservices- 
based applications with multiple client applications. 


ee 


= Similar to the facade pattern from object-oriented design, 
but it is a distributed system reverse proxy or gateway 
routing for using in synchronous communication. 


Aemayed Idy 


) 


= The pattern provides a reverse proxy to redirect or route 
requests to your internal microservices endpoints. I--------4 L------------------------------------+ 


= API Gateway provides a single endpoint for the client 
applications, and it maps the requests to internal 
microservices. 
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API Gateway Pattern - Summarized 


= API gateway locate between the client apps and the 
internal microservices. 


= Working as a reverse proxy and routing requests from 
clients to backend services and provide cross-cutting 
concerns like authentication, SSL termination, and cache. 


= Several client applications connect to single AP! Gateway 
possible to single-point-of-failure risk. 


= If these client applications increase, or adding more logic to 
business complexity in API Gateway, it would be anti- 
pattern. 


Aemayed Idy 


) 


= Best practices is splitting the API Gateway in multiple 
services or multiple smaller API Gateways: BFF-Backend-_ '--------- ee 
for-Frontend Pattern. 


= Should segregated based on business boundaries of the 
client applications. 
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Main Features of API Gateway Pattern 


= Reverse Proxy and Gateway Routing 
Reverse proxy to redirect requests to the endpoints of the internal microservices. Using Layer 7 routing for 
HTTP requests for redirections. Decouple client applications from the internal microservices. Separating 
responsibilities on network layer and abstracting internal operations. 


= Requests Aggregation and Gateway Aggregation 
Aggregate multiple internal microservices into a single client request. Client application sends a single request 
to the API Gateway and it dispatches several requests to the internal microservices and then aggregates the 
results and sends back to the client application in 1 single response. Reduce chattiness communication. 


= Cross-cutting Concerns and Gateway Offloading 
Best practice to implement cross-cutting functionality on the API Gateways. Cross-cutting functionalities can be; 
Authentication and authorization, Service discovery, Response caching, Retry policies, Circuit Breaker, Rate 
limiting and throttling, Load balancing, Logging, tracing, IP allowlisting. 


Routing Authentication 

Request Aggregation Authorization 

Service Discovery with Consul & Eureka Throttling 

Load Balancing Logging, Tracing 

Correlation Pass-Through Headers/Query String Transformation 


Quality of Service Custom Middleware Mehmet Ozkaya 308 


esign Adapt 


Request Flow of API Gateway Pattern 


Rate Limiting Protocol 
Circuit Breaker Conversio 
d A 
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Client Load Balancing” 
Logging Authenticatio 
Monitoring Authorization 

Token Management 


Identity 

Server 
_ Authenticatio 
Authorizatio 


Request 
Validation 


, Service d Protocol 
Discovery conversions 


IP a 
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Architectures Patterns&Principles 


Before Design — What we have in our design toolbox ? 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices 
Communications 


HTTP Based RESTful API 
GraphQL API 

gRPC API 

WebSocket API 

Gateway Routing Pattern 


Gateway Aggregation 
Pattern 


Gateway Offloading 
Pattern 


API Gateway Pattern 
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Evaluate:Microservice Architecture with API Gateway 


Benefits 

e Reverse proxy, Routing, Aggregation 
e Abstraction Backend services 

e Reduces chattiness network traffic 

« Implements Cross-cutting concerns 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Client Apps has Different UI Requirements To 


Clients code has custom logic to re-format these 
data. 

Client codes complex and hard to maintain for 
future developments. Also it increase browsers } 
usage of high resources. e 


Problems 
e Frontend client applications has different Ul and --------- NEE ----- ---------------- S 
Data consumption requirements i GAENE APPS ! Microservices 
. Different data representation requirements need | 1 
extra effort to adapt data for specific Client Ul : e 
n Ki 4 
"i f li 
"i i J 
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Different UI 
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Backends for Frontends Pattern - BFF 


= Backends for Frontends pattern basically separate API 
Gateways as per the specific frontend applications. 


= Single API Gateway makes a single-point-of failure. 


= BFF offers to create several API Gateways and grouping 
the client applications according to their boundaries. 


= A single and complex API Gateway can be risky and 
becoming a bottleneck into your architecture. 


= Larger systems often expose multiple API Gateways by 
grouping client type like mobile, web and desktop 
functionality. 


= Create several API Gateways as per user interfaces to 
provide to best match the needs of the frontend environment. 


A wm wm em em em em em em eee mm mm mm zm mm zm SS SE SE mm eee mm wo = = sl 


= BFF Pattern is to provide client applications has a focused 
interfaces that connects with the internal microservices. 


Sea sea wm ep ep em em em om sl 
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Backends for Frontends Pattern - BFF 
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Architectures Patterns&Principles 


Before Design — What we have in our design toolbox ? 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices 
Communications 


HTTP Based RESTful API 
GraphQL API 

gRPC API 

WebSocket API 

Gateway Routing Pattern 


Gateway Aggregation 
Pattern 


Gateway Offloading Pattern ° 


API Gateway Pattern 


Backends for Frontends 
Pattern-BFF 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Evaluate:Microservice Architecture with BFF 


Benefits (0 La- Se ee ee 
e Client focused Interfaces Client Apps ! Microservices 
e Minimal logic on the frontend code 
e Streamline data representation > 
- Well-focused interface for the frontend 

s Shopping 
Cart 


gau 


EE? = am Zem “anal 


client applications 


ba 


Drawbacks 

e Increased Latency 

e Good for large-scaled microservices 
application which has several client 
applications 
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Service-to-Service Communications between 
Backend Internal Microservices 


= Created API Gateways and separate this API Gateways 
following the BFF Pattern. 


= Sync request comes from the clients and goes to internal 
microservices over the API Gateways. 


= What if the client requests are required to visit more than 
one internal microservices ? How we can manage internal 
microservice communications ? 


Addltem 


much as possible. 


= |n some cases, we can't reduce these internal Client | 3 GetPrice 


communications due to operation need to visit several 
internal services. 


m 
l 
I 
' 
I 
l 
1 
U 
I 
U 
I 
I 
I 
l 
U 

= Best practice is reducing inter-service communication as ! a 
l 
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= Client send query request to internal microservices to ee 4 
accumulate some data in the sceen page of frontend. 
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Service-to-Service Communications between 


Backend Internal Microservices-2 


= User addlitem into shopping cart, these operation EE l 


need to get data from Product and Price microservices. Service-to-Service Communications 


= Synchronous communcation over the API Gateways 
which is the Request/Response Messaging. 


= The client send http request to the microservices for 
querying or adding item into Shopping Cart: 1 


Addltem 


= 1- The client send request to API Gateway 


i 
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| 
i 
i 
l 
| 
I 
] 
i 
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I 
I 
I 

= 2- API Gateway dispatch request to ShoppingCart , 

= 3- SC need to extend information by sending sync request to : 

Product and Pricing microservices l 
U 
I 
U 
I 
I 
I 
| 


=" Internal calls makes coupling each microservices. 


= If one of the microservices is down, it can't return 
data to the client so its not any fault-tolerance. 


Mehmet 


|z GetProduct 


3 GetPrice 
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Service-to-Service Communications Chain Queries 


= |f service calls are much then a few HTTP calls to 


multiple microservices, than it goes to un-manageable rr E 
ituati Service-to-Service Communications - 
situation. 


Chain Queries 


A 


2 |GetProduct 


= Place Order Use Case: client checkout shopping cart, 
start order fulfillment processes. 


= Request/Response Sync Messaging end up with 6 
sync chain HTTP Request. 


= Increase latency and negatively impact the 
performance, scalability, and availability. 


= What if the step 5 or 6 is failed ? 


= We can apply 2 way to solve this issues: 
= 1- Change microservices communications to async way 


= 2- Use Service Aggregator Pattern to aggregate some query 
operations in 1 API Gateway. L 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Service-to-Service Communications Wäi 


Chain Queries 


ss ees a tS SS ec item me a Sé 
Problems . . . Service-to-Service Communications - 
e HTTP calls to multiple microservices Chain Queries 

e Chain Queries 


, Visit more than a few microservices ( Product 


e Increased latency 
2 |GetProduct 


Solutions 
e Aggregate query operations 
e Service Aggregator Pattern 


Client 
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Service Aggregator Pattern 


= Service Aggregator Pattern is receives a request 
from the client or API Gateway. EE EE E 


= Dispatches requests of multiple internal backend 
microservices. 


Addltem 
Aggregator 


4 


= Combines the results and responds back to the 


initiating request in 1 response structure. 4 
= Reduces chattiness and communication overhead Additem , 


between the client and microservices 


= Addltem aggregates request data from to several 
back-end microservices: Product - SC and Pricing. 


ShoppingCart 


= Centralizing its logic into a specialized tee Sé 
microservice. 


= Isolates the underlying additem operation that 
makes calls to multiple back-end microservices. 
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Service Registry/Discovery Pattern 


= Microservice Discovery Patterns and Service Registry 
provide to register and discover microservices inthe enee 4 
cluster. 


= Why We Need Service Discovery Pattern ? 
When deploying and scaling microservices, more 
microservices and instances could be added to the 
system to provide scalability to the distributed 


a Client 
application. 


QU“ 
Service ’ Z (Pring) 


= Service locations can change frequently, more 
dynamic configuration is needed for the microservice 


architecture. 


= IP Addresses and network locations are dynamically 


assigned and often change due to auto-scaling features. Register 


et 
SZ 


= Service Registry and Discovery pattern allows to find ---------------------------------------- 
the network locations of microservices without injecting 
or coupling services. 
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What is Service Discovery Pattern? 


= To find the network locations of microservices, the service 
discovery pattern is used in microservices applications. 


= It will provide to register and discover microservices in the 
cluster. 


l 

U 

I 

I 

U 

I 

U 

= API Gateways for routing the traffic with client and internal ! 

microservices. How API Gateways access the internal 
backend microservices ? | Client 

I 

U 

I 

I 

U 

U 

l 

| 

| 

| 

| 

| 

| 

I 


= Service discovery pattern uses a centralized server for 
«Service registry» to maintain a central view of microservices 
network locations. 


= Services update their locations in the service registry at 
fixed intervals. Clients can connect to the service registry and 
fetch the locations of microservices. S 


= There are 2 main service discovery patterns: 
= Client-side service discovery 


= Server-side service discovery 
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How Does Service Discovery Work? 


= 3 participants: Service Registry, Client, Microservices 
= Client service finds the location of other service instances by e E 
querying a Service Registry. 


=" Internal backend services register to Service Registry 
service before. The Service Registry is a database for 
microservice instances. 


= The service registry keeps records of the network locations 
of the microservices. 


= When the client service need to access internal services, then 
it will query from Service Registry and access them. 


l 
| 
I 
I 
I 
I 
I 
I 
I 
I 
I 
| Client 
I 
I 
U 
U 
I 
| 
i 
= Clients can find the locations of microservices using the l 
service registry and directly call them. À 
= Netflix provides a service discovery pattern called «Netflix 
Eureka» 


= Kubernetes container orchestrator automatically handle to 
service discovery operations. Mehmet Ozkaya 328 


Architectures Patterns&Principles 


Before Design — What we have in our design toolbox ? 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices 
Communications , 


HTTP Based RESTful API . 


GraphQL API e 
gRPC API 
WebSocket API R 


Gateway Routing Pattern 

Gateway Aggregation Pattern 
Gateway Offloading Pattern 
API Gateway Pattern 


Backends for Frontends 
Pattern-BFF 


Service Aggregator Pattern 


Service Registry/Discovery 
Pattern 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
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Put products into the 
shopping cart 


Apply coupon for 
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Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Design: Microservices Architecture with 
Service Aggregator, Registry/Discovery Pattern 


Client Apps! 
J DIIIL, | Catalog 
ı Aggregator | 
| 


| Service “ 
Registry "< e 
eege EEN Ordering 
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Evaluate: Microservice Architecture with 
Service Aggregator, Registry/Discovery Pattern 


Benefits 
Aggregator 


e Abstract operations that calls to multiple back-end 
microservices 

e Centralizing logic into a specialized microservice 

Registry/Discovery 

e Provide to register and discover microservices in 
the cluster 

e Keep track of microservice locations beforehand 


Shopping 
Cart 


Vi V L 7 
f \ 
Ww QA 
mmm emm emm emm em emm em em em em em em em ep ep ep SE eae wm wm wm wm ee wm 
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Drawbacks 

e Increased Latency 

e Good for large-scaled microservices application 
which has several client applications 


e Only for Sync communications problems 
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Adapt: Microservice Architecture with 
Service Aggregator, Registry/Discovery Pattern 


Frontend SPAs presesses i potes- --------------------------------------- 
Client Apps! Microservices Service Aggregator and Registry Patterns 

e Angular i 

e Vue 

- React 


ff f/ er, | Catalog > E 
| Aggregator 
1 


API Gateways 

e Kong Gateway 

e Tyk API Gateway 

e Express Gateway 

, Amazon AWS API Gateway 
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Service 
a Regist 
Service Registry ee 
e Netflix Eureka randona d L ee ee se e e ss e e se se e se eae eee ee SSE 882 88 em em wm em wm — 
e Kubernetes Backend Microservices Database 
e Serverless Orchestrators . Java — Spring Boot e MongoDB — NoSQL Document DB 


e Nei — Asp.net , Redis — NoSQL Key-Value Pair 


e JS — NodeJS e Postgres — Relational EES, e 


Service-to-Service Communications Chain Queries 


= |f service calls are much then a few HTTP calls to 


multiple microservices, than it goes to un-manageable rr E 
ituati Service-to-Service Communications - 
situation. 


Chain Queries 


A 


2 |GetProduct 


= Place Order Use Case: client checkout shopping cart, 
start order fulfillment processes. 


= Request/Response Sync Messaging end up with 6 
sync chain HTTP Request. 


= Increase latency and negatively impact the 
performance, scalability, and availability. 


= What if the step 5 or 6 is failed ? 


= We can apply 2 way to solve this issues: 
= 1- Change microservices communications to async way 


= 2- Use Service Aggregator Pattern to aggregate some query 
operations in 1 API Gateway. L 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Long Running Operations Can't Handle with "nich: 


Sync Communication 


Problems Fer ee ee ee ee ee ee wm = = = em em em wm wm mm mm mm mm el 
, HTTP calls to multiple microservices Pree eerie PORN ne 


e Chain Queries Rate 
e Visit more than a few microservices ( Product 
« Increased latency with Highly Coupling Services 

e Performance, scalability, and availability problems | | 


2 |GetProduct 


Best Practices 

e Minimize the communication between the internal 
microservices 

e Make microservices communication in 
Asynchronous way as soon as possible. 


Client 3 etPrice 


Solutions 7 
e Asynchronous Message-Based Communications 
e Working with events 
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Microservices 
Asynchronous Message- 
Based Communication 


Benefits and Challenges of Asynchronous Communication 

Asynchronous Message-Based Communication Types in Microservices Architecture 
Single-receiver Message-based Communication (one-to-one model-queue) 
Multiple-receiver Message-based Communication (one-to-many model-topic) 
Fan-Out Publish/Subscribe Messaging Pattern 

Mehmet Ozkaya 


336 


Architecture Design — Vertical Considerations 


Modular : : 
pene Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Problem: Long Running Operations Can't Handle with "nich: 


Sync Communication 


Problems Fer ee ee ee ee ee ee wm = = = em em em wm wm mm mm mm mm el 
, HTTP calls to multiple microservices Pree eerie PORN ne 


e Chain Queries Rate 
e Visit more than a few microservices ( Product 
« Increased latency with Highly Coupling Services 

e Performance, scalability, and availability problems | | 


2 |GetProduct 


Best Practices 

e Minimize the communication between the internal 
microservices 

e Make microservices communication in 
Asynchronous way as soon as possible. 


Client 3 etPrice 


Solutions 7 
e Asynchronous Message-Based Communications 
e Working with events 
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Microservices Synchronous Communication 


= Synchronous communication is using HTTP or gRPC 
protocol for returning synchronous response. 


= The client sends a request and waits for a response from 


the service. 
= The client code block their thread, until the response reach( 
from the server. Client 


Http / gRPC 
= The synchronous communication protocols can be HTTP or se ail iar 


HTTPS. 


= The client sends a request with using http protocols and 
waits for a response from the service. 


rrr em eee em e e eee eee = wm wm em om wm = 


= The client call the server and block client their operations. 


= The client code will continue its task when it receives the 
HTTP server response. 
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Microservices Asynchronous Communication 


= The client sends a request but it doesn't wait for a 
response from the service. The client should not have 
blocked a thread while waiting for a response. 


= AMQP (Advanced Message Queuing Protocol) 


using message broker systems like Kafka and RabbitMQ 


= Using AMQP protocols, the client sends the message with A 
queue. 


Client 
= The message producer does not wait for a response. 


= Message consume from the subscriber systems in async 
way, and no one waiting for response suddenly. 


= If there is busy interactions in communication across 
multiple microservices, then use asynchronous 
messaging platforms. 
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Microservices Asynchronous Communication-2 


= Message brokers are responsible for handling 
the message sent by the producer service in 
async messaging-based communication. Microservices Async Communication 


with Message Broker 


= Ifthe consumer service is down at the 
moment, the broker might be configured to retry 
as long as necessary for successful delivery. 


= Messages can be persisted if required or 
stored only in memory. 


= Message broker is responsible for delivering 
the message. 


= No longer necessary for both microservices to 
be up and running for successful Eeer 
communication. 


= Async messaging provides loosely couple 
communication. 
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Problem: Chain of request and highly coupled ee ga H 


dependent microservices 


Service-to-Service Communications - 
Chain Queries 


A D 


2 |GetProduct 


Client 
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Benefits of Asynchronous Communication 


= New Subscriber Services 
Adding new services is very simple. We can easily subscribe to 
message that we want to receive. The producer doesn't need to be 
know about subscribers, we can remove and add subscribers without 
affecting producer service. 


= Scalability 
With async communications we can easier to manage scalability a 
issues, can scale producer, consumer and message broker system 
independently. Scale services according to incoming messages into "en 
event bus system. Kubernetes KEDA Auto-scalers. 


= Event-driven Microservices 
With async communication, we can provide event-driven 
architectures which is best way to communicate between 
microservices. 


= Retry mechanisms 
Brokers can retry to sending message and keep trying automatically 
without any custom solutions. 
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Challenges of Asynchronous Communication 


= Single Point of Failure - Message Broker 
The message broker becomes a single point of failure. We should 
not rely of all communication with a single node of message brokers, 
instead we should scale it and use hybrid communication with sync 
and async in your cases. 


=» Debugging 
difficult to debug issues with async communication, it can be hard 
trace the flow of a single operation across service boundaries. 
debugging of the flow and the payload of events takes so many = 
times and hard to debug at the same time. 


= At-least-once delivery and Not Guarantee an order of messages 
Mostly Brokers use at-least-once delivery and not Guarantee order 
of messages. Should embrace these message delivery mechanism 
with applying idempotency consumers and not designing FIFO 
requires cases. 
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Asynchronous Message-Based Communication 


= Use Asynchronous message-based communication when 
you have multiple microservices are required to interact 
each other without any dependency. 


= Asynchronous message-based communication is works with ee ee ee 
events. 


= Events can place the communication between microservices: a 
Event-driven communication. 


Client 
= If any changes happens in microservices, it is propagating 


changes across multiple microservices as an event. 
= Events consumed by subscriber microservices. 


= Event-driven communication bring us Eventual consistency. 
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Asynchronous Message-Based Communication-2 


m i Adapt 


"H 


a 


Client 
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2 Type of Asynchronous Messaging Communication 


Single receiver message-based communication 
one-to-one(queue) model or 
Point-to-point model 


Multi receiver message-based communication 
one-to-many (topic) model or 
publish/subscribe model 
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Single-receiver Message-based Communication 1-1 


= one-to-one (queue) or point-to-point communications. 


= If you send 1 request to the specific consumer, and this operation will take long time, use 
this Single-receiver async one-to-one communication. 


= Single producer and single receiver; implementation as a Command Pattern. 


Single-receiver message-based communication 


CreateOrder 
Command 
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Multiple-receiver Message-based Communication 


= Publish/subscribe mechanisms that has multiple receivers. 


= Producer service publish a message and it consumes from 
several microservices by subscribing message on the — -------- i pi ed a =.-.----- < 
message broker system. 


= Publisher don't need to know any subscriber, no any OrderSubmitted A somes) 
dependecy with communication parties. S Sg ! 

' ` > N i 

= one-to-many (topic) implementation has Multiple receivers. Each ;'— 1 
request can be processed by zero to multiple receivers. 


= Publish/subscribe used in patterns Event-driven microservices 
architecture. ee 


= Message broker system is publishing events between multiple 
microservices, subscribing these events in an async way. 


= Messages are available to all subscribers and the topic can 
have more than one subscriber. 


= The message remains persistent in a topic until they are deleted. 


Meh k 
= Kafka, RabbitMQ or Amazon SNS and EventBridge. SE, Së 


Multiple-receiver Message-based Communication 


= Microservice publishes an event when something happens. Price change in a product microservice: 
Price Changed event can subscribed from SC microservice in order to update basket price. 
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Multi-receiver message-based communication 


BE) 


Client 


OrderSubmitted 
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= Event-driven Architecture, CQRS pattern, event storming, eventual consistency principles. 
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Dependency Inversion Principles (DIP) 


= Provide to broke dependency of classes by inverting dependencies, inject dependent classes via 
constructor. 


= Upper-level modules or classes and lower-level classes must not be dependent on modules. 


= Lower-level modules must be dependent on higher-level modules (interfaces of modules). 


Without Dependency Inversion With Dependency Inversion 


Business Logic «interface» 
IRepository 


Data Access SqiDatabase Data Access SqiDatabase 


Mehmet Ozkaya 352 


Problem: Chain of request and highly coupled ee ga H 


dependent microservices 


Service-to-Service Communications - 
Chain Queries 


Broke Dependencies following ER 


DIP by changing communication 
da Moyes Way 2 |GetProduct 


Client 


SEENEN Mehmet Ozkaya 353 


Fan-Out & Message Filtering with 
Publish/Subscribe Pattern 


= Fan-out is a messaging pattern; ‘fanned out’ to multiple 
destination in parallel. 


= Each of destinations can work and process this messages in 
parallel. 


= Publisher/subscriber model to define a topic which is 
logical access point to enabling message communication with 
asynchronously. 


= Publisher sends the message to the topic, message is 
immediately fanned out to all subscribers of this topic. 


= Each service can operate and scale independently and 
individually that completely decoupled and asnycronously. 


= The publisher and the subscribers don’t need to know who is 
publishing / consuming this message that is broadcasting. 


= Deliver the same message to multiple receivers is to use the 
Fanout Publish/Subscribe Messaging Pattern. 
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Publish/Subscribe Messaging Pattern 


= Publish/subscribe messaging is a form of asynchronous 
service-to-service Communication. 


= Any message published to a topic is immediately received 
by all of the subscribers to the topic. 


= Enable event-driven architectures, and decouple 
applications to increase performance, reliability and scalability.°’“°'s""* 


= Applications are decoupled into smaller, independent 
building blocks that are easier to develop, deploy and 
maintain. 


=" Publish/Subscribe (Pub/Sub) messaging provides instant PUBLISHER 
event notifications for these distributed applications. 


= A message topic provides a lightweight mechanism to 
broadcast asynchronous event notifications. 


= All components that subscribe to the topic receive every 
message, unless a message filtering policy is set by the 
subscriber. 


f=) 
2 i) Ge 
BER 


SUBSCRIBER 


TOPIC 
SUBSCRIBER 


SUBSCRIBER 
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Publish/Subscribe Messaging Pattern-2 


S) m 2 
PUBLISHE 
ee ee et ese i ee e > TH Q eer 
© E en 
PUBLISHER 


Mehmet Ozkaya 356 


SUBSCRIBER 


Topic-Queue Chaining & Load Balancing Pattern 


= Use a queue that acts as a buffer between the service to avoid loss data if the service to fail. 


= Services can be down or getting exception or taken offline for maintenance, then events will be loses, 
disappeared and can't process after the subscriber service is up and running. 


= Put Amazon SQS between EventBridge and Ordering microservices. 


= Store this event messages into SQS queue with durable and persistent manner, no message will get lost. 
Queue can act as a buffering load balancer. 


SE AWS Cloud EventType = 
SGD Poll-based 
Ve 


Amazon SQS Notification 


Publish EventType = 
TT HTTP Call He Message STL Poll-based 
va ZS el V Ve sem 
(ESCH i ZE 


Client di 
Application API Gateway Order Acknowledgment Amazon SNS | Amazon SOS Inventory 
REST Microservice 


EventType = 
Poll-based 


GS, 
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a 
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Architectures Patterns&Principles 


Before Design — What we have in our design toolbox ? 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices Microservices Async FR 
Communications Communications . [ist products 
HTTP Based RESTful API e Single-receiver e Filter products as per 
Message-based brand and categories 
Graph@L API Communication (one-to-, Put products into the 
gRPC API one model) shopping cart 
WebSocket API e Multiple-receiver e Apply coupon for 
Message-based discounts 


Gateway Routing Pattern 
Gateway Aggregation Pattern 
Gateway Offloading Pattern 
API Gateway Pattern 


Backends for Frontends 
Pattern-BFF 


Service Aggregator Pattern, 


Service Registry/Discovery 
Pattern 


Communication (one-to- 


many model-topic) Checkout the shopping 


cart and create an orde 


Dependency Inversion . List my old orders and 


Principles (DIP) order items history 
Fan-Out Non-FR 
Publish/Subscribe 8 
Messaging Pattern e High Scalability 


Topic-Queue Chaining &° High Availability 
Load Balancing Pattern . Millions of Concurrent 
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e Independent 


Design: Microservices Architecture with 
Fan-Out Publish/Subscribe Messaging Pattern 


Client Apps Microservices 


Catalog Ss 


Par 
Eos 


Aemaye5 IdV 
EEKISEEEDKEGETd 


D 
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Adapt: Microservice Architecture with 
Fan-Out Publish/Subscribe Messaging Pattern 


"ctor ras D ee re ee ye ee ees ae 
Frontend SPAS Client Apps Microservices 
e Angular 


e Vue 
Weg? d Catalog Ss 
= Shopping © 
U : N 
| 8 4 
Keek 
Ee 


API Gateways 

e Kong Gateway 

e Tyk API Gateway 

e Express Gateway 

, Amazon AWS API Gateway 


aJyOXg JƏVSSIN 


Fy 


reer eseee2 Se E E Sig E E mp wm wm wm wm vm em wm em wm 


Message Brokers 


e Kafka eon See Sa SS ee ee 
e RabbitMQ Backend Microservices Database 
e Amazon EventBridge, SNS . Java — Spring Boot - MongoDB — NoSQL Document DB 


e Nei — Asp.net , Redis — NoSQL Key-Value Pair 


, JS — NodeJS - Postgres — Relational Mehmet Ozkaya 360 


Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservice Architecture with 
Fan-Out Publish/Subscribe Messaging Pattern 


Benefits 

e Adding new subscriber services very easily = = ---------- 
e Se Client Apps 

e Increase flexible scalability 

e Distribute received messages at scale 

e Event-driven Microservices 


Drawbacks 

e Single Point of Failure - Message Broker 

e Hard to Debugging 

, Not Good for FIFO and exact-once requirements !---------- 
can cause performance and scalability problems 


Pe fi 


Microservices 


Catalog © 


Es 
= 
Es 


Aemaye5 IdV 
JON JƏVSSIN 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Database Bottlenecks when Scaling paler 


Considerations 
e State-less or state-ful services 
- Are they can scale independently? = # ;--------- 


© Scale Stateful Application Horizontal Scaling | ordering Q 
e Service and Data Partitioning along Business Se 
Boundaries - Shards/Pods = ——— 
e Use NoSQL Database to gain easy partitioning 
features 


Client Apps i Microservices : 
: L ; i 
Problems | 7 Se 
e Database are stateful service i ' Catalog E n 
. è I i = 
e Scaling stateful services are not easy 1 C) | D 1 
i i ; : D fe ay > Shopping @ Wa H 
e Vertical scaling has limits need to scale Web E T | cart” [Se > ! 
i m 
horizontally i 9 o v 
I e bd ? O 
, | OO Gi? sl 3 
Solutions 4 : 
| popid $ $ 
1 li 
í li 
1 1 
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Optional Section: 
Learning Kafka and RabbitMQ Architecture 


= Message broker system that provide to communicate Asynchronously between microservices. 


= Kafka and RabbitMQ is good example of distributed architecture that is good to learn with 
microservices. 


= Optional Section, you can Skip section. 


PARTITION 0 


KH Write PARTITION 1 
Producer rite 
rarrmon2 — 0] [+ |[2 |[ 3 ]{«][s}Le]iz 
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Kafka and RabbitMQ 
Architectures [OPTIONAL] 


Kafka Components: Topic, Partitions, Offset and Replication Factor 

Apache Kafka Cluster Architecture:Kafka Brokers and Zookeeper 

Apache Kafka Core APIs:Producer, Consumer, Streams and Connect API 
RabbitMQ Components: Producer, Queue, Consumer, Message, Exchange, Binding 


RabbitMQ Exchange Types 
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What is Apache Kafka ? 


= Apache Kafka is the most popular open-source event 
streaming platforms. 


= Designed for horizontally scalable, distributed, and fault- 
tolerant 
= Distributed publish-subscribe event streaming platform 
= Publishers send messages to topics, subscriber of a topic 
receives all the messages published to the topic. 
= Event-driven Architecture: Kafka is used as an event 


router, and the microservices publish and subscribe to the 
evenis. 


= Distributed working, and it provides a horizontal scalable 
system. 


= Built on top of ZooKeeper synchronization service. 


= Key Components: Topics, Partitions, Brokers, Producer, 
Consumer, Zookeeper 
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Apache Kafka Benefits 


= Reliability 
Kafka is distributed, partitioned, replicated and fault 
tolerance. So it is also High Availability. 


= Scalability 
Since its distributed architecture, Kafka scales easily without 
any down time. 
= Durability © © 
Kafka uses Distributed commit log. This persists to events 
on disk as log commit very fast. Its durable for infinitive or a 
given parameter days or weeks. 


= Performance 
Kafka has high throughput for both publishing and 
subscribing messages. It is distributed event streaming 
platform capable of handling trillions of events a day. 


= Kafka has better throughput, built-in partitioning, replication, 
and fault-tolerance architecture. 
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Apache Kafka Use Cases 


=» Messaging 
Message brokers are used to decouple services from each 
other. In event-driven architecture, Kafka is used as an event 
router, and microservices publish and subscribe to the events. 


Mobile SaaS Apps 
Edge 


= Metrics 2 a ZS al e Global-scale 


Kafka is often used for operational monitoring data. ech - 
Aggregating statistics from distributed applications to produce : i e : menace 
f f p — Ki Ech a_ e Persisten orage 
centralized feeds of operational data. Ces SS =% =e S =) Seege 
= Log Aggregation : : ; i o 


e Real-time 


Log aggregation solution that collect logs from multiple Kl a : a € SC 88 kafk 
services. Log aggregation collects physical log files servers S lg 
and puts them in a central place for processing. "rm rem rs 


= Stream Processing 
Kafka process data in processing pipelines consisting of 
multiple stages. Storm and Spark Streaming read data from a 
topic and processes it. 
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Apache Kafka Use Cases 


= Website Activity Tracking 
Kafka follows the user activity tracking pipeline as a set of 
real-time publish-subscribe feeds. 


= Event Sourcing em — ` 
Kafka is using with the event-driven architecture, so in that e 0 S e ee 
cases also can be using for event storing and event sourcing. d : ; ` 


e Real-time 


ls nS TATA e Persistent Storage 
Apache Ka fka z arar net =: -rere 
aS = eo) Stream Processing 


S L ee 
S 
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Kafka Components: 


Topic, Partitions, Offset and Replication Factor 


PARTITION 0 Beene 


Poe y S 
H: Offsets” 
ennan a 
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Apache Kafka Cluster Architecture: 
Kafka Brokers - Kafka Cluster 


Kafka can be set up across multiple servers, which are 
called Kafka Brokers. 


Mostly prefer to run multiple Kafka broker instance at the 
same time into our Kafka cluster. 


Kafka Cluster 
With multiple brokers, we can get the benefit of data 
replication, fault tolerance, and high availability of your 
Kafka cluster. 


Kafka cluster consists of multiple brokers to maintain load 
balance. 


Topic N 
Kafka brokers are stateless, so they use ZooKeeper for 


maintaining their cluster state. 


Kafka broker instance can handle hundreds of thousands 
of reads and writes per second. 


Kafka broker leader election can be done by ZooKeeper. 
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Apache Kafka Cluster Architecture: 
Zookeeper 


How we are managing and coordinating Kafka brokers ? 
Kafka Cluster and including Kafka brokers need to manage. 


Management job is handled by the master node in the 
distributed systems. 


Kafka Cluster 


This master node manage and maintenances the other 
worker(nodes) in order to work correctly. 


In Apache Kafka, there isn’t any master in the Apache Kafka producer 
Cluster. 


ZE ; E Topic N 
Apache Kafka Cluster isn't a master-worker architecture; it’s a X 


master-less architecture. 


ZooKeeper is used for managing and coordinating Kafka 
broker. The zookeeper manages and maintains the brokers 
in the cluster. 


Finds which brokers have been crashed or which broker 


recently added to the cluster and manage their lifecycle. 
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Apache Kafka Core APIs: 
Producer, Consumer, Streams and Connect API 


= Producers API 
Producers push data to brokers. Publish a stream of data to 
Kafka topics. When the new broker is started, all the 
producers search and sends a message to that new broker 


= Consumer API 
Consumer API provide to subscribe to topics and process the 


=] tel 


streams of data. Manage messages have been consumed NT y WE? 


from Kafka by using partition offset. Consumer offset values 


are managed by ZooKeeper. Connectors 


= Streams API —s 
Streams API that is useful for transforming data from one 
topic to another. Allows applications to act as a stream 


processor. Transforming the input streams to output streams 


KA Ri eege 
KA Processors 


a, 


App 


Provide to implement connectors that pulling data from 
external systems into Kafka. Use stream data between Kafka 
and other external systems. Collect metrics from servers into 
Kafka topics. 


Consumers 


Mehmet Ozkaya 374 


What is RabbitMQ ? 


= RabbitMQ is a message broker software that implements 
the Advanced Message Queuing Protocol (AMQP). 


= It allows applications to communicate with each other by 
sending and receiving messages through queues. 


= RabbitMQ is a message queuing system that transmit a 
message received from any source to another source. 


= Similar ones can be listed as Apache Kafka, Msmq, 
Microsoft Azure Service Bus, Kestrel, ActiveMQ. 


=" All transactions can be listed in a queue until the source to 
be transmitted gets up. 


= It allows to send and receive messages asynchronously. 


= RabbitMQ’s support for multiple operating systems and 
open source code is one of the most preferred reasons. 


= Main Components of RabbitMQ: Producer, Queue, 
Consumer, Message, Exchange, Binding and FIFO. 


Rabbit 
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RabbitMQ Components: Producer, Queue, Consumer, 
Message, Exchange, Binding 


PRODUCER ké 


BROKER 


Binding Key aries 
attern 
BINDINGS 
PDF process eu.de.* 


QUEUES 


Da RabbitMQ 


https://www.cloudamqp.com/img/blog/exchanges-topic-fanout-direct.png 
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RabbitMQ Queue Properties 


= Queue Name 
The name of the queue we have defined. 


= Durable 
Determines the lifetime of the queue. If we want persistence, we have to set it true. 


= Exclusive 
Contains information whether the queue will be used with other connections. 


= AutoDelete 
Contains information about deletion of the queue with the data sent to the queue passes to the consumer side. 


producer queue consumer 


https://www.rabbitmq.com/tutorials/amqp-concepts.html 
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RabbitMQ Exchange Types 


= RabbitMQ provides four types of exchanges: 
Direct, Fanout, Topic, and Headers. 


= Direct Exchange 
Uses of a single queue is being addressed. 
The most appropriate queue is reached with MISTS 
the relevant direct exchange. 


Exchange 


publish routes consumes 


Queue 


= Topic Exchange 


Message Broker 


Messages are sent to different queues 
according to their subject. Incoming 
message Is classified and sent to the related 
queue. 


* Topic Exchanges 
* Fanout Exchanges 
s Header Exchanges 


|. Direct Exchanges 

= Variation of the Publish / Subscribe pattern. 
Topic Exchange should be used to 
determine what kind of message they want 


to receive. 


https://www.rabbitmq.com/tutorials/amqp-concepts.html 
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RabbitMQ Exchange Types-2 


Fanout Exchange 

Used in situations where the message should be sent 
to more than one queue. Especially applied in 
Broadcasting systems. 


Mainly used for games for global announcements. 


Headers Exchange 

Guided by the features added to the header of the 
message. Routing-Key used in other models is not 
used. 


Transmits to the correct queue with a few features and 
descriptions in message headers. 


The attributes on the header and the attributes on the 
queue must match each other’s values. 


= rates.* 
To p i c Routes 


Exchanges 
Routing Key : 
stocks. * 


* department.tech.* 


Fanout E ee 


Exchanges 


wä 


https://www.rabbitmq.com/tutorials/amqp-concepts.html 
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RabbitMQ Architecture 


= The producer never sends any messages directly to a 
queue. Instead, the producer can only send messages 
to an exchange. 


= Exchange has 2 sides: it receives messages from 
producers, it pushes them to queues. 


= Exchanges control the routing of messages to queues 
according to exchange types. 


= RabbitMQ uses a push model. 


= Push-based queues can overwhelm consumers if 
messages arrive faster than the consumers can process 
them. 


= Each consumer can configure a prefetch limit. 


= Push model is to distribute messages individually and 
quickly, and ensure that work is concurrent way. 


= Messages are processed in the same order how they 
arrived in the queue. 


PRODUCER > <4 


BROKER 
Binding Key Bam 
BINDINGS GE 
PDF process eu.de.* 
Queues ee oO 
Da RabbitMQ 
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Scale the Microservices 
Architecture Design 


Stateless and Stateful Application Horizontal Scaling 
The Scale Cube 
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Proble m 


Learn: Scalability - Vertical Scaling - Horizontal Scaling iene 


pt 


= Scalability is the number of requests an application can 


handle 
, Vertical Scali 
: Measured by the number of requests and It can effectively iene ete (RAM 
support simultaneously. “PU etc) ) 


= To prevent downtime, and reduce latency, you must EI Leileiel 


scale 
—— 
a Horizontal scaling by adding more machines https://www.webairy.com/horizontal-and-vertical-scaling/ 


= Horizontal scaling and vertical scaling both involve adding 
resources to your computing infrastructure 


= |f no longer handle any more simultaneous requests, it has Horizontal scaling 
reached its scalability limit. piinia 


= Vertical scaling by adding more power 
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Vertical Scaling - Scale up 


= Vertical scaling is basically makes the nodes stronger. 


= Make the server stronger with adding more hardware. Adding more Vertical Scaling 
resources to a single node. ( Increase size of instance (RAM 


CPU etc.) ) 


= Make optimization the hardware that will allow you to handle more 
requests. 


= Vertical scaling keeps your existing infrastructure but adding more 
computing power. 


= Your existing code doesn't need to change. 


= Adding additional CPU, RAM, and DISK to cope with an increasing 
workload. 


= By scaling up, you increase the capacity of a single machine. And it has 
limits. That is named Scalability Limits. EI 

= Because even the hardware has maximum capacity limitations. 

= For handling millions of request, we need horizontal scaling or scaling out. 
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Horizantal Scaling - Scale out 


= Horizontal scaling is splitting the load between different servers. 


= Simply adds more instances of machines without changing to existing 


specifications. Horizontal Scaling 
= Share the processing power and load balancing across multiple ( Add more instances 
machines. 


= Horizontal scaling means adding more machines to the resource pool. 


= Preferred way to scale in distributed architectures. 


" Scaling horizontally gives you scalability but also reliability. A e H H 


= When splitting into multiple servers, we need to consider if you have a 


state or not. 
eg Ai 


= if we have a state like database servers, than we need to manage more 
considerations like CAP theorem. 
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scale the Microservices Architecture Design Ls 


Monolithic Architecture 


E-Commerce 
Wf VY, 
| Shop Ul | 
| Catalog Service | 
| SC Service | 
Lika 

TIES, PEIA 
Discount Service| 

ng m 
| Order Service 


eee eee 


See es es =... e = = m m ee ee ee me et 


Microservices Architecture - Message Broker 


Shopping (A | 
yy 


Discount 


emaze idy 
yYJyO0Yg JI9YSSIN 


Ordering 
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The Scale Cube 


= X-Axis: Horizontal Duplication and Cloning of services and 


data 


e l = 3 Dimensions of Scaling 
= Y-Axis: Functional Decomposition and Segmentation — 


Microservices 


= Z-Axis: Service and Data Partitioning along Customer 


Boundaries - Shards/Pods Y axis - fuctional 


S os : : decomposition 
= Functional decomposition can be achieved by decoupling Scale by splitting 


your architecture into functions with Y-axis. ee 
= WMicroservices is an example for functional decomposing. 


= Y-axis scaling splits the application into multiple, different X axis - horizontal Z axis - data partioning 
rvices duplication Scale by splitting data 
Se " Scale by Clonning 


= Combining both X and Y-Axis scaling with microservices 
architecture can give better scalability. 
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Stateless and Stateful Application Horizontal Scaling 


= Scalability of our architecture to handle more 
number of concurrent requests. 


= Ifthe scaling server don’t have state, just put the 
different servers and have a load balancer that direct 
the traffic. 


resources for exiting servers. 1 Client Apps 

= Horizontal Scaling "scaling out" is splitting the load l 
between different servers. SES 

= Ifthe server have a state or not ? Je i 
oO 


= Orhestrator tools like Kubernetes have replica sets 
and we can increase to pod numbers easily. 


cree scress WG we we e eler we we ep ep en ep em wm em wm = — 


Microservices 


Catalog © 


Eas 
Ee 
Ee 
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How to Scale Stateful Application Horizontal ? 


How can we manage this stateful data when scaling the application ? 


CAP Theorem to manage stateful server horizontal scaling operation. 


Microservices are "stateless" services that can scale easily. 


Databases have "state" and need to consider CAP Theorem when horizontally scaling for stateful servers. 


aaa o e - em S| J 
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Microservices 


ANE Stateless| 
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2 type of Consistency Level 


= What is the consistency level requirements of our 
microservices databases ? 


= 2 type of "consistency level: 


= Strict Consistency | Client Apps | ae oo "Microservices oe 1 
When we save data, the data should affect and seen | In | Stateless] Vif l 
immediately for every client. Debit or withdraw on bank! : Yip z ) 
account. ti > MEM Bl i 
i l H > N 
= Eventual Consistency “or 8 iti da f "i 
When we write any data, it will take some time for ! o! A S d 
, . . ' i 5 Discount fa K 
clients reading the data. Youtube video counters. r L < D : 
1 LB - ` 

a j j j . 

When we horizontally scaling with the stateful | Ordering 
i l i i 
d t l 


database services, should split the data which is 
calling sharding. 


= Database sharding is also the way of partitioning 
and splitting database servers. 


= How can we manage data in distributed systems ? MehmetOdaya. 3% 


Microservices Data 
Management - Choosing 
Right Database 


Polyglot Persistence, Database-per-Service Pattern, Shared Database Anti-pattern 
Relational and NoSQL Databases 

CAP Theorem — Consistency, Availability, Partition Tolerance 

Data Partitioning: Horizontal, Vertical and Functional Data Partitioning 

Database Sharding Pattern 
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Architecture Design — Vertical Considerations 


—— Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Microservices Data Management - Main Topics 


Modular i : 
Microservices 


Monolithic 


Choosing Right 


Decomposition 


Communications 


Data Management 


Commands and Distributed 


Queries Transactions 


Database 
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Problem: Database Bottlenecks when Scaling paler 


Problems 

e Database are stateful service 
e Scaling stateful services are not easy = = 7--------- 
e Vertical scaling has limits need to scale 
horizontally 


Microservices 


Catalog © 


ae 
Ets 
Ee 


Solutions 

e Scale Stateful Application Horizontal Scaling 

e Service and Data Partitioning along Business 
Boundaries - Shards/Pods 

e Use NoSQL Database to gain easy partitioning 
features 


= 
m 
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Question 
e How to Choose a Database for Microservices ? 
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Every microservice has its own data, the data integrity and 
data consistency should consider very carefully. 


Microservices should not share database with each other. 


Microservices share data over the application microservices 
with using Rest APIs. Broke the unnecessary dependencies 
between microservices. 


If there is an update on 1 microservices database schema, 
the update shouldn’t be directly affect to other microservices. 


Limit the scope of changes on microservices when any 
database schema changes happened. 


We can pick different databases as per microservices which 
database can pick the best option: "polyglot persistence" 
principle. 


Challenges: Duplicated or partitioned data can make problems 
of data integrity and data consistency. Strict or Eventual 
consistency. 


Monolithic Microservices 


— SS 

wan 
Catalog Service Catalon S Ed 
atalog Service 
Ml 


| "es 
== "oss 


Polyglot Persistence 


REST API REST API |!| REST API 
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Polyglot Persistence Principle in Microservices-2 


= In monolithic applications can’t be duplicate and not be any data 
consistency problems, strict database transaction management. 


= Microservices architecture, we have to welcome duplicate datas 


and eventual consistency. PAG Ir, BS 
= How we can welcome duplication and un-consistent data ? | l h 
= Accept eventual consistency data in microservices where it is i 

possible. 
= Define our consistency requirements before design the system. | | sc Service | Service 


= |f need to strong consistency and ACID transactions, we should 


follow traditional approaches. = 


= Use event driven architecture: microservices publish an event 
when any changes happened on data model. 


= Subscriber microservices consume and process event 
afterwards in eventual consistency model. 


= Polyglot Persistence gives us scale independently and avoid 
sigle-point-of-failure of bottleneck databases. 
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Microservices Database Management Patterns 
and Principles 


Managing a microservices database is challenging job, should have a strategy. 
ACID: atomicity, consistency, isolation and durability. Wee 


Challenging to implement queries and transactions that visits to several 
microservices. 


Microservices Database Management Patterns and principles: 
The Database-per-Service pattern 

The API Composition pattern 

The CQRS pattern 

The Event Sourcing pattern 

The Saga pattern 


The Shared Database anti-pattern 
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Microservices Database Management Patterns 
and Principles - Overview 


= The Database-per-Service Pattern 
In order to be a loose coupling of services, each microservice should 
have its own private database. Design database architecture for 
microservices. 


= The API Composition Pattern 
Retrieving data from several services also need a set of patterns and 
practices. When implements a query by invoking several 
microservices, we will follow the API Composition, Gateway 
Aggregation patterns for combining the results. 


= The CQRS Pattern | 
The command query responsibility segregation (CQRS) is provide to | 
seperate commands and queries database in order to better perform ! 
querying several microservices. la 


konsistency 


= The Event Sourcing Pattern 
The Event Sourcing pattern basically provide to accumulate events 
and aggregates them into sequence of events in databases. We can 
replay at certain point of events. 


i 
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Microservices Database Management Patterns 
and Principles — Overview 2 


= The Saga Pattern SAGA Patter 
Transaction management in really hard when it comes to L es ) (Payment } Leen ) ESA E 
microservices architectures. We use Saga Pattern to Ce SE ‘shipment e Notify S 
implementing transactions between several microservices è Sr E 
and maintaining data consistency. Co Cessëe/ 

= The Shared Database Anti-Pattern / complete SS 
You can create a single shared database with each service CZ 


accessing data using local ACID transactions. But it is against 
i ; ; i É The Shared Database Anti-Pattern 
to microservices nature and will cause serious problems in 


the future of applications. | [ Rest api | 
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Microservices Data Management — Patterns and Principles 


Modular 
Monolithic 


Microservices 


Choosing Right Commands and Distributed 


Decomposition 
Communications 


Data Management 


Database Queries Transactions 


e Polyglot persistence e The API Composition e The Saga Pattern 
e The Database-per-Service « The CQRS pattern 
e The Shared Database Anti- e The Event Sourcing 

Pattern Pattern 
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The Database-per-Service Pattern 


= Microservices should be loosely coupled, scalable, and 
independent. When shifting to the monolithic architecture to 
microservices architecture, should decomposes The Database-per-Service pattern 


databases. i | 
= Distributed data model with many smaller databases for pallet 
particular microservice. , 3 WY 
i i \ è Shopping 
= Data schema changes can perform without any impact Catalog) ; Cart 
on other microservices, Changes to an individual database : 
don't impact other services. | i l 
CF //, i 
= There isn’t a single point of failure in the application, the LL 
application is becomes more resilient. wy) an 


= Individual databases are easier to scale, if 1 service peek 
the requests that only that microservice can scale 
independently. 
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The Database-per-Service Pattern-2 


= Separating databases can gives us to ability to pick the best optimized database for our 
microservices. 


= Can choices include relational, document, key-value, and even graph-based data stores. 


= Using the most efficient database depending on the service requirements and functionality. 


The Database-per-Service pattern 


REST API RESTA REST API 


Pl 
\ 
| Shopping 
Cart 


/ 


Catalog 


“MUU 


Mehmet Ozkaya 401 


Drawbacks of Database-per-Service Pattern 


= Services need a communication method to exchange data, 
inter-service communication. 


= Each service must provide a clear API, that need to make 
resilience of these communications like applying retry and 
circuit breaker patterns. 


= Distributed transactions across microservices can 
negatively impact consistency and atomicity. 


= Complex queries, no simple way to execute join queries on 
multiple data stores. 


The Database-per-Service pattern 


REST API 


\ 
Catalog 


“MUD 


RESTA 


Pl 
Shopping 
Cart 


KL 
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The Shared Database Anti-Pattern 


= |f we don’t follow Database-per-Service pattern and use 
Shared Database for several microservices = Anti-Pattern 
The Shared Database Anti-Pattern 


REST API REST API 


Ordering 


= It is against to microservices nature and will cause 
serious problems in the future of applications. 


= When using a shared database, the microservices lose 
their core properties: scalability, resilience, and 
independence. Catalog 


| Vos 


= You will face to develop big a few monolithic applications 
instead of microservices. 


Anti-Pattern 


= Shared database can block microservices due to single- 
point-of-failure. 


= If shared database seems to be the best option for the 
microservices project, should re-think that we really need 
the microservices, the monolith would be the better choice. 
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The Shared Database Anti-Pattern - Pros and Cons 


Benefits 


= Transaction management, that we don't need to span the 


. f . The Shared Database Anti-Pattern 
transactions over the microservices. 


REST API REST API 


= Decrease duplicate data. Since data is fully constrained, we | 
1 ff 


can easily execute complicated queries with joins. 


= Able to follow ACID. Consistency of data and state easily Catalog Shopping Ordering 
manage when process fails. 

Drawbacks 

= WMicroservices with shared databases can't easily scale. - 


= Shared database will become a single point of failure. 


= Microservices won't be independent in terms of 
development and deployment. 
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Polyglot Persistence 


= WMicroservices enables using different kinds of data 
storing technologies. 


Polyglot Persistence 


= Each development team can choose the persistence 


technology that suits the needs of their service best. REST API | 


= Martin Fowler - Polyglot persistence will come with a 
cost - but it will come because the benefits are worth it. 


REST API 


Ordering 


REST A 


Shopping 


Catalog Cart 


= When relational databases are used inappropriately, 
they give damaged on application development. 


= Example of looked up page elements by ID, much 
better suited to a key-value No-SQL databases than 
relational databases. 


= How to Choose a Database for Microservices ? 
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Database Choises - Relational and NoSQL Databases 


= Relational and NoSQL are two types of database 
systems commonly implemented in microservices 
architecture. 


= New approach of databases which is called NewSQL. 


= Relational and NoSQL are different in terms of the 
storing data, and accessing data. 
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Relational Databases - RDBMS 


= Relational databases provides storing data into related data tables. , 
| Relational 
= Relational database tables have a fixed schema, use SQL to 


manage data and support transactions with ACID principles. 


= Atable uses columns and rows for storing the actual data. Each 
table will have a column that must have unique values—known as 
the primary key. 


= When one table’s primary key is used in another table, this 
column in the second table is known as the foreign key. 


= On microservices, we should not consider using single big 
relational database. 


= The main advantages of Relational database is ACID compliance. | 
one change fails, the whole transaction will fail. 


= Polyglot persistence in microservices, still relational databases is SQL 
good option some certain type of problems. 


= Example of relational databases are Oracle, MS SQL Server, 
MySQL, PostgreSQL. Mehmet Ozkaya 407 


No-SQL Databases (Non-Relational Databases) 


= No-SQL databases has different types of stored data and 


data models: Document, Key-value, Graph-based, [ key ] “Value y 
Column-based databases. igi 
= Ease-of-use, scalability, resilience, and availability [ey we » 
characteristics. eet ll 
= NoSQL databases stores unstructured data, and this gives Det — e 


huge performance advantage. 


= NoSQL stored unstructured data in key-value pairs or 
JSON documents. NoSQL 


= No-SQL databases don't provide ACID guarantees. 


= Drawback is transaction management. 


Wide 
Column Document 
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No-SQL Document Databases 


= Document databases stores and query data in JSON-based 
documents. 


= Data and metadata are stored hierarchically. 

= Objects are mapping to the application code. 

= Don’t have to run JOINs or decompose data across tables. 
= Scalability, document databases can distributed very well. 
= Best choise for content management and storing catalogs. 


= Le products data can store in document database for e- 
commerce applications. 


Document 


= Example Document Databases: MongoDB and Cloudant. 
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No-SQL Key-Value Databases 


= Data is storing as a collection of key-value pairs in Key- 
value NoSQL database. 


= Data is represented as a group of key-value in the 
database. 


= Best choise for session-oriented applications. 


= Le storing customer basket data into key-value 
database. 


= Example Key-Value Databases: Redis, Amazon 
DynamoDB, Azure CosmosDB, Oracle NoSQL Database. 


Key-Value 


[key | gin, 
Value 
Les 


Del — we 
De — 


e ~N 
Value J 


Rn ` mg 
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No-SQL Column-Based Databases 


= Column-based databases also known Wide-Column Databases. 


= Data is stored in columns, by this way, it can access necessary 
data more faster than if we compare to storing data in rows. 


= If you select mostly same columns in your databases, its good 
to use this databases. 


= |t doesn't scanning the unnecessary information in a whole 
row. 


= Column-based databases can scale by columns 


independently. e 
l Wide 
= Columns could be different database servers. 
Column 


=" Le building a Data warehouse, Big Data processing. 


= Apache Cassandra, Apache HBase or Amazon DynamoDB, 
Azure CosmosDB. 
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No-SQL Graph-Based Databases 


= Graph-based databases is stores data in a graph structure into 
node, edge, and data properties. 


= Data entities are connected in nodes. 


= The main benefit of a graph-based databases is to store and 
navigate graph relationships. 


= |.e. fraud detection, social networks, and recommendation 
engines. 


= Example of Graph-based databases are OrientDB, Neo4j, and 
Amazon Neptune. 
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When to Use Relational Databases ? 


= ACID compliance, Data Consistency 
Relational database is ACID compliance. ACID - Atomicity, 
Consistency, Isolation, and Durability (ACID) guarantees the reliability 
of database transactions. 


= If one change fails on database, database should remain in the YÁ 
previous state that was before the transaction. 

= Data Consistency is fully provided, if you need strong consistency, 
good to choose Relational Databases, supports complex transactions. 


= Predictable Data, Low Workload Volume 
If application data is predictable, as per structure, size, and frequency 
of access, within thousands of transactions per second, relational 
databases are still the best choice. 


Basically | 
Available 


Eventually 
Consistent ` 


= Normalization also reduce the size of the data on disk by limiting 
duplicate data and anomalies. 
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When to Use Relational Databases ? - 2 


= Read Requirements, Complex Join Queries 
Relational Database has a fixed schema. When relationships between 
tables are important and data is highly structured and requires 
referential integrity. 


= Can work with complex queries, table joins and reports on normalized 
data models. 


C=) 


= Relational Database supports a powerful SQL query language. 


= Deployments, Centralized Structure | 
Relational Databases will be deployed to large and one or few 
locations. Relational database has centralized structure. Available 


d 


Eventually 
Consistent ` 


= Relational databases have a single point of failure with failover. 


= Relation database is deployed in vertical fashion. 
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When to Use No-SQL Databases ? 


= Flexible Schema, Dynamic Data Database Choises 
NoSQL Database has no fixed schema. Allows to add or remove : 
attributes into their model with dynamically. When your data is dynamic 
and frequently changes. 


= Use case of implement an loT platform that stores data from different VA 
kinds of sensors with frequently changed the attributes of your data. 
=" Un-predictable Data, High Workload Volume 
When you have high volume workloads and needs to horizontal scale 


with low latency. NoSQL databases have been designed for the cloud 
that naturally good for horizontal scaling. 


Basically | 
Available 


Eventually 
Consistent ` 
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= NoSQL Databases prioritize partition tolerance that designed for handling 
large amount of data or data coming in high velocity. 


= Frequently Change Data and Read Requirements 
When data is dynamic and frequently changes and Relationships are de- 
normalized data models and Data retrieve operations are simple and 
performs without table joins. 


When to Use No-SQL Databases ? - 2 


= Data Consistency, BASE Model - Basically Available, Soft State, Database Choises 
Eventually Consistent 
NoSQL Database is only eventually consistent and don't support 
transactions, focus on high volume data and horizontal scaling. 


= Write Performance Requirements f 
NoSQL Database compromise consistency to achieve fast write 
performance, offers to fast write operations with Eventual consistency. 


= Not Good for Complex Join Queries 
NoSQL Databases perform best when data is stored in the same format 
not require to relation and join operations. 


Basically | 
Available 


Eventually 
Consistent 
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= Deployments, De-centralized Structure 
NoSQL is scale horizontally so data is replicated across different 
geographical zones and provides better control over consistency, 
availability, and performance. 


= NoSQL databases have no single point of failure, has decentralized Durability 


structure, gives both read and write scalability, deployed in horizontally. 


Best Practices When Choosing Data Store 


= Use Right Tool for Right Job, Use the best data store for your data. 


= Don't use Relational Database Everywhere 


If using Relational Database for all microservices, would probably 
going wrong way, consider other data stores to data requirements. 


= Don't use Single Data Store Technology, Differentiate 


Choose Alternatives to relational databases; Key/value stores 


Document, Search engine, Time series, Column family, Graph IRA 
databases. DDA 


= Focus The Data Type That Need to Store 
Consider the type of data that you have. 


Store JSON documents in No-SQL Document database. 
Put transactional data into a Relational SQL database. 


Use a time series data base for telemetry databases. 
Choose Blob Data Storage for blob datas. 
Put application logs into Elastic Search Databases. 


REST AI 


Shopping 


Cart 


Polyglot Persistence 


REST API 
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Best Practices When Choosing Data Store - 2 


= Trade-offs between Availability and Consistency 
Understand the Trade-offs between Availability and Consistency. 
Should prefer High Availability over strong consistency as soon 


as possible to scale horizontally. (the CAP theorem) DEET EE 


T API 
Shopping / 


= Transactional Boundaries Between Microservices CAG, 
Consider business Transactional Boundaries Between 


Microservices, that data need to consistent across those 


microservices. Prepare for compensating transactions in case of Catalog 
fail. 


= Competence of Development Teams 4 
Consider your team competences about database technologies. 
Skill set of your development team should cover optimize 
queries and tune for performance improvements. 
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Problem: Database Bottlenecks when Scaling, EEH le HI 
Different Data Requirements For Microservices 


Problems 

e Database are stateful service 
e Scaling stateful services are not easy EE 
e Vertical scaling has limits need to scale Horizonta! 
e Different Data Requirements For Microservices 


Microservices 


Catalog 3S 

Solutions kae 

, Scale Stateful Application Horizontal Scaling Cart ` Les 

e Service and Data Partitioning along Business 
Boundaries - Shards/Pods 


e Use NoSQL Database to gain partitioning me 
e Identify Database Requirements following best 


practices l---------- Geleet 
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How to Choose a Database for Microservices ? 
(Question Set) 


Data Consistency Level Database Choises 


Do we need Strict-Strong consistency or Eventual consistency ? 


Do we need ACID compliance ? Should follow Eventual consistency 
in microservices to gain high scalability and availability. 


Fixed or Flexible Schema Choise, Predictable or Dynamic Data d 
Are we work with fixed or flexible schema that need to change 
frequently, dynamically changed data ? 


Are we have Predictable Data or Dynamic Data ? 


High or Low Data Volume, Predictable or Un-predictable Data 
Are we work with High Volume Data or Low Volume Data ? 


Can we have predictable data that we store our microservices 
database ? 


NoSQL Databases prioritize partition tolerance that handling large 
amount of data or data coming in high velocity. 


Mehmet Ozkaya 


Basically | 
Available 


d 


Eventually 
Consistent ` 
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How to Choose a Database for Microservices ? 
(Question Set) - 2 


= Read Requirements, Relational or non-Relational Data, Complex Database Choises 
Join Queries , 
Our data is highly structured and requires referential integrity or not 
required for relationships that is dynamic and frequently changes ? 


= Should it work with complex queries, table joins and run SQL queries Vi 
on normalized data models or Retrieve data operations are simple 


and performs without table joins ? 


= Deployments, Centralized or De-centralized Structure 
Do we deployed to large and one or few locations with centralized 
structure ? or Do we need to deploy and replicate data across 
different geographical zones ? 


Basically | 
Available 


= High Performance Requirements 
Do we need to achieve fast read-write performance ? 


Eventually 
Consistent ` 
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Durability 


How to Choose a Database for Microservices ? 
(Question Set) - 3 


= High Scalability Requirements Database Choises 
Do we need High Scalability Requirements both vertical and s 
horizontally scaling ? 


= To accomodate millions of request should sacrifice strong consistency. 


= High Availability and Low Latency Requirements d 
Do we need High Availability and Low Latency Requirements that 
need to separate data across different geographical zones ? 


= Can we provide ALL OF THESE FEATURES at the same time ? 
Is it possible to provide High Scalability, High Availability and Low 
Latency with High Performance and able to run Complex Join Queries 
providing with ACID principles strong data consistency ? 


Basically | 
Available 


Eventually 
Consistent ` 
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= Unfortunatelly, NO. 
= WHY ? 
= The CAP Theorem. 


CAP Theorem 


= Found in 1998 by a professor Eric Brewer. 


= Consistency, Availability, and Partition Tolerance cannot all 
be achieved at the same time. 


= Distributed systems should sacrifice between consistency, 
availability, and partition tolerance. 


= Any database can only guarantee two of the three concepts; 
Consistency, Availability, and Partition tolerance. 
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CAP Theorem — Consistency, Availability, 
Partition Tolerance 


= Consistency 
When the system get any read request, the data should return 
last updated value from database under all circumstances. If 
the data cannot be retrieved, an error should be throw. When 
consistent not provide, the system must block the request until 
all replicas update. 


= Availability 
The ability of a distributed system to respond to requests at any 
time. That is a distributed system can respond all request any 
time. Even if one node in any cluster is down, the system 
should be able to survive with other nodes. (fault-tolerance) 


= Partition Tolerance 
Network partitioning; parts of system are located in different 
networks. The ability of the system to continue its life in case of 
any communication problem. Guarantees the system continues 
to operate if one node is down. 
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Consistency and Availability at the same time ? 


= If there is Partition Tolerance, either Availability or 
Consistency should be selected. Should sacrifice Availability 
or Consistency in distributed systems. 


= Partition Tolerance is a must for distributed architectures. 
The emergence of NoSQL databases is to easily overcome 
the Single Point of Failure problem. 


= Relational databases prevent distribute data from different 
nodes. NoSQL databases don't include foreign keys, joins, 
that is, relations between data. 


= Un-related data allows it to be stored in a distributed 
manner, NoSQL databases easily scalable. 


= Distributed system doesn't have the luxury of not providing 
Partition Tolerance anyway. 


= MongoDB, Cassandra; None of them gave up on Partition 
Tolerance, and made a choice between Availability and 
Consistency. 
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Consistency and Availability at the same time ? - 2 


= In Distributed architecture, Partition Tolerance seems to be a 
must-have feature. it is necessary to choose between 
Consistency or Availability. 


= If a system is to be fully consistent, it must be sacrifice that 
always available. (High Availability) 


= If it is desired to be accessible at all times, the consistency 
should be sacrificed. 


= |n microservices architectures choose Partition Tolerance 
with High Availability and follow Eventual Consistency. 
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Scale Database in Microservices 


= Problem of Single Database Server 
= Why we need to use Data Partitioning ? 


Client Apps 


Microservices 


= Scaling databases in microservices architecture 


Ky Stateless | 
= Splitting database servers with Database Sharding 


= Single Database Server leads to low performance 


Aemaye5 idy 
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Problem: Single Database Server Performs 


Low Performance 


Problems 

e Databases become very slow by time with app grows 

« Single database goes un-manageble situation 

e Database operations are become slower 

e Very low performance due to slowness of single 
database 

e Running out of disk space 


Microservices 


Stateless 7 
Services, Catalog Up i 
DB Services 


Solutions 
e Data Partitioning 


e Horizontal, Vertical, and Functional Data Partitioning 
e Improve availability 
e Increase scalability 
e Increase performance 
e Improve security 
e Improve data management, Operation 


CEKISCIEEVEECIV 
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What is Data Partitioning ? 


= Data Partitioning is divides a large dataset into several 
small partitions. 


= Data is divided into partitions that can be easily aaa | r 


managed and accessed separately. 


= Distributes data across different partitions to 
improve database availability, scalability and 
performance. 


= Abstracting partitioning architecture from the client 
applications. 


= Client applications seems as a single unit 
databases. 
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Why we are using Data Partitioning ? 


= Increase Scalability 
When divide data across multiple data partitions into 


separate db servers, we can scale out the system Horizontal Partioning Vertical Partioning 


without worrying any hardware limits. ( Sharding) ( Row Splitting) 


= Improve Availability 
With Separating data across multiple servers, we 
protect our systems for a single point of failures. 


= Increase Performance (Query and operations) 
Instead of querying whole database, system query only|f7q | Sha 
smaller components. : 


= Improve Security 
By storing sensitive and non-sensitive data into differen 
partitions. 


= Improve Data Management 
Due to divide tables and indexes with different 
partitions, its more easy to manage small units and 
easy to maintenance. Mehmet Ozkaya 430 


Horizontal, Vertical, and Functional Data Partitioning 


= There are three methods for partitioning data: 


= Horizontal Partitioning (often called sharding) and we 


; Deeg? Horizontal Partioning Vertical Partioning 
mostly use this portioning 


( Sharding) ( Row Splitting) 
= Vertical Partitioning 


= Functional Partitioning 
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Horizontal Partitioning - Sharding 


Horizontal partitioning is also called sharding. 


Each partition is a separate data store, but all partitions 
have the same schema. 


Shards holds a specific subset of the data. 


Splitting the table data horizontally based on partition 
key. 


Tables are divided to smaller tables that table rows are 
stored different partitions. 


CUSTOMER FIRST 


NAME 
Alice 
Bob 


1 


The partition key provide to distribute data among all the 
partitions. 


3 
4 


Carrie 
David 


With the partition key, database locate the specific 
partition. 


Data requests are spreading the load over more servers 
and provide more performance. 


The disadvantages of horizontally partitioning could be 
the setting wrong partition key. 


Vertical Shards 


Original Table 


FIRST 
NAME 


LAST 


CUSTOMER | 
ID NAME 


CITY 


Anderson 


Best 


Alice Austin 


Bob Boston 


1 
2 
3 Conway Chicago 
4 Doe Denver 


Horizontal Shards 


Austin 


FIRST 
NAME 


Alice 
Bob 


LAST 
NAME 


LAST 
NAME 


Anderson 


Best 


Anderson Austin 


Best 


VS2 
CUSTOMER CUSTOMER 
ID CITY ID 
1 
2 


Boston Boston 


1 
2 

C 3 Chi 
conway icago Hs2 
Doe 4 Denver 


CUSTOMER FIRST 
ID 


NAME 


LAST 


NAME E 


3 
4 


Carrie 


David 


Conway Chicago 


Doe Denver 


An Overview of Sharding & Partitioning | Hazelcast 
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Vertical Partitioning 


= Vertical partitioning is a "Row Splitting". 


= Each partition holds a subset of the columns for table 


in the database. Original Table 
= The data divided based on columns and we can divide SSC 
by mostly visited columns and the other columns in E E epee fee 
different servers. eegen 
= Frequently accessed columns can be use in one TEEN Horbontali Sharda 


vertical partition and less frequently accessed fields in 


KO VS2 HS1 
an other CUSTOMER FIRST | LAST CUSTOMER CITY CUSTOMER FIRST LAST city 
d ID NAME NAME ID ID NAME NAME 
1 


Alice Anderson 1 Austin 1 Alice Anderson Austin 
= Example case: Facebook, the user profile data can be in 2 Bob Best 2 Boston 2 Bob Best Boston 
different partition and user mostly visited data can be ope ff oe ber 
di CUSTOMER FIRST LAST city 
ifferent server. D | NAME | NAME 
3 Carrie Conway Chicago 
= Benefit of Vertical Partitioning is you can separate the : SS dE 


critical and mostly visited columns in a separate server. 


An Overview of Sharding & Partitioning | Hazelcast 


= Best practice: Divide by rarely-changes and frequently- 


change columns into different servers. Mehmet Ozkaya 433 


Functional Partitioning 


= The data is divided by following the bounded context or 
subdomains. 3 Dimensions of Scaling 


= Data is segregated according to usage of bounded 
contexts in the system. 


= Its like decomposing microservices as per responsibilities 


Y axis - fuctional 


with considering bounded contexts. decomposition 
i Soe . R . SE Scale by splitting 
= Functional partitioning into Microservices Decomposition small services 
section. 


= Apply functional partitioning following the Decomposition 


patterns: -------------------------------- ----- --4 X axis - horizontal Z axis - data partioning 
Identify Bounded Context Boundaries for Each Microservices duplication Scale by splitting data 
Scale by Clonning 


Customers Orders 


Payment Shopping Cart 
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Database Sharding Pattern 


= Sharding is "a small piece or part", meaning to be a small 
piece or part of something. 


= Database sharding is the separation of the data into ji X 
unique small pieces of database which called shards or ee SE 
chunks. | | 


= When storing and accessing large volumes of data in 


_ Data Access Data Access 

microservices architectures, we should divide a databases 

into a set of horizontal partitions or shards. | 
= Each shard has the same schema, holds its own distinct 

subset of the data. 

Data A-Z 

= Shardings enable to scale the system with adding new Data A-I ` Dein Data S-Z 

shards according to storage needs. 

, Unsharded Data Sharded Data 

= |tcan improve performance and reduce contention by 

balancing the workload across different shards. https://www.redhat.com/architect/pros-and-cons-sharding 


= We can gain cloud power with locating physical servers 


closely which users can access the data performantly. Mehmet Ozkaya 435 


Database Sharding Pattern - 2 


= Databases dividing into shards with partition keys. 


= These partition keys provide to decide which data should be 
placed in each shard. ji X 


= The partition key should be static. It shouldn't affect by the Command/Query Commad/Query 
data changes. | | 

= Database Sharding provides dividing a data store Data Access Data Access 
physically and organizes the data into shards. | 

= When an application retrieves data by querying database, | | | 
the sharding logic redirects the application to the correct 


shard server. Pas 
, , Data A) ` DataJ-R Data S-Z 
= All these database sharding operations are abstracting the 


physical location of the data in the sharding logic from client = Unsharded Data Starded Data 
applications. 


https://www.redhat.com/architect/pros-and-cons-sharding 
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Benefits of Database Sharding Pattern 


= Increase Scalability 
When divide data across multiple data partitions into 
separate db servers, we can scale out the system without 


worrying any hardware limits. 
Command/Query 


= Improve Availability | 
With Separating data across multiple servers, we protect our 
systems for a single point of failures. Bein Ancass 
= Increase Performance (Query and operations) | 


Instead of querying whole database, system query only 
smaller components. 


= Improve Security es 
By storing sensitive and non-sensitive data into different 
partitions. Unsharded Data 


= Improve Data Management 
Due to divide tables and indexes with different partitions, its 
more easy to manage small units and easy to maintenance. 


Commad/Query 


| 


Data Access 


| 


Data A-I Data J-R Data S-Z 


Sharded Data 


https://www.redhat.com/architect/pros-and-cons-sharding 
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Tinder System Design Example of 
Database Sharding Pattern 


= Tinder is very good example of Database Sharding Pattern. 


= Tinder allows to match and meet other people who use the 
application near you (around 160km) based on location. 


= To find people near you very quickly and offer choices thal 
meet the criteria what you set. 


= How Tinder match peoples who are near to each other ? 
= [inder segments users based on their location. 


= This is called GeoSharding, that is, location-based 
database sharding. 


= Sharding by dividing the world map into boxes with their Re a 


locations and matches them in only into that box locations in 
the world. 
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Cassandra No-Sql Database oe ee H 
Peer-to-Peer Distributed Wide Column Database 7 ae 


Cassandra is very good example of implementation Database 
Sharding Pattern and using Horizontal Scaling features. 


Cassandra is a distributed database from Apache Foundation. 


lt is highly scalable and designed to manage very large 
amounts of structured data. 


It provides high availability with no single point of failure. 


Apache Cassandra is a highly scalable, high-performance 
distributed database designed to handle large amounts of 
data across many different located servers. 


Apache Cassandra feautures; 
= Elastic scalability - It is scalable, fault-tolerant, and consistent. 
= No single point of failure. 
= Column-oriented database. 
= Flexible data storage. 
= Easy data distribution. 


7 


cassandra 


Sg KEE Al JP 
ww" 
AU yd 4.900.006 CA Toronto 
IN ca EH 


bh 4 
https://cassandra.apache.org/_/cassandra-basics.html 
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Cassandra Architecture 


ApacheCassandra™= NoSQL Distributed Database 


1 Installation = 1 NODE 
v Capacity + 1TB 
v Throughput: 3000 Tx/sec/core 


DataCenter | Ring 


Communication: 
v Gossiping 


https://cassandra.apache.org/_/cassandra-basics.html 
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Why Cassandra No-SqlI Database ? 


= Cassandra has an auto-sharding feature and it 
helps keep data divided among nodes. 


= All of the columns that will decide on which node 
the data should be kept are called "Partition Key". 


= Partition Key is set to Sensor# and Date. 


= The data will be stored in nodes determined by 
inserting the value of these two columns with hash 
function. It becomes Partition Keys. 


= CAP Theorem: either Availability or Consistency 
must be selected in a distributed system. 


= Microservice architectures decided that 
Availability is more important to them and sacrifice 
for strict consistent and embrace to Eventual 
Consistency would be sufficient. 


Sensor # Date 


2015-01-01 
2015-01-02 
2015-01-02 


2015-01-02 
2015-01-02 
2015-01-02 
2015-01-02 


Partition Key 


Timestamp 
20150101-000000 
20150101-000010 
20150101-000020 
20150102-000000 
20150102-000010 
20150102-000020 
20150102-000000 
20150102-000010 
20150102-000020 


Clustering Key 


Primary Key 


https://cassandra.apache.org/_/cassandra-basics.html 


Metric1 
5.01 
5.01 
5.05 
5.01 
5.01 
5.05 
6.01 
6.01 
6.05 


Metric2 Metric3 


5.67 
5.67 
5.8 
5.67 
5.67 
5.8 
7.67 
7.67 
8.8 
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0.678 
0.678 
0.678 
0.678 
0.678 
0.678 
0.978 
0.698 
0.679 


Architectures Patterns&Principles 


Before Design — What we have in our design toolbox ? - Previous 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices Microservices Async FR 
Communications Communications . [ist products 
HTTP Based RESTful API e Single-receiver e Filter products as per 
Message-based brand and categories 
Graph@L API Communication (one-to-, Put products into the 
gRPC API one model) shopping cart 
WebSocket API e Multiple-receiver e Apply coupon for 
Message-based discounts 


Gateway Routing Pattern 
Gateway Aggregation Pattern 
Gateway Offloading Pattern 
API Gateway Pattern 


Backends for Frontends 
Pattern-BFF 


Service Aggregator Pattern, 


Service Registry/Discovery 
Pattern 


Communication (one-to- 


many model-topic) Checkout the shopping 


cart and create an orde 


Dependency Inversion . List my old orders and 


Principles (DIP) order items history 
Fan-Out Non-FR 
Publish/Subscribe 8 
Messaging Pattern e High Scalability 


Topic-Queue Chaining &° High Availability 
Load Balancing Pattern . Millions of Concurrent 
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e Independent 
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Before Design — What we have in our design toolbox ? - Data 


Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by ° 


scalability 
The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices Data 
Management Patterns 


Microservices Data 


Management 


The Shared Database Anti- 


pattern 


Relational and NoSQL 
Databases 


CAP Theorem — 


Consistency, Availability, 


Partition Tolerance 


Data Partitioning: 


Horizontal, Vertical and 


Functional Data 
Partitioning 


Database Sharding Pattern 


Non-FR 
High Scalability S 
High Availability i 


Millions of Concurrent 
User 


Independent 
Deployable 


Technology agnostic . 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an orde 


List my old orders and 
order items history 
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Design: Microservices Architecture 
with Database Sharding Pattern 


[ome Los 
BS 
KR 
Cart À 

Horizontal 
S Data Partitioning 
Lë 1 cb 
e OE 


= 
m 
N 
N 
> 
Q 
m 
D 
2 
O 
A 
m 
a 


Kema}e5 dy 


Ce: 
‘| Ordering i @ 


Peer-to-Peer Distributed Wide Column Database Mehmet Ozkaya 444 
Master-Master (Master-less) architecture 


Adapt: Microservice Architecture with 
Database Sharding Pattern - Cassandra 


Frontend SPAs sss We pr rm em e mm www wwe wwe ewww www ewww ew ew ween eee 


A | 1 Client Apps i Microservices 

« Angular A 

GEN | Aedes 

o React : ce = 
API Gateways A j - LA H 
e Kong Gateway 1 " U k DB, > 
- Express Gateway T 2 ene D o 
- Amazon AWS API Gateway ! E S e Data Partitioning} æ 
Message Brokers ! Pa ZS | Discount K M 
. Kafka ' ry = ye 

- RabbitMQ | oem d O 

, Amazon EventBridge, SNS 1 ' i i DB) 
Backend Microservices E E EE 
e Java — Spring Boot No-SQL Database Cloud No-SQL Database 

. Net — Asp.net e Cassandra — NoSQL Peer-to-Peer . Amazon DynamoDB 

. JS — NodeJS e MongoDB — NoSQL Document DB . Azure CosmosDB 


« Redis — NoSQL Key-Value Pair Mehmet Ozkaya 445 


Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservice Architecture with 
Database Sharding Pattern - Cassandra 


Benefits 

Distributed Horizontally Scaled Databases that 

ready for Kubernetes Deployments 

e Data Partitioning: Horizontal and Functional Data 

Partitioning 

Database Sharding Pattern: Increase Database 

Scalability, Improve Availability, Manageability 

e Master-Master (Master-less) architecture with 
Peer-to-Peer Distributed Wide Column Database 


Horizontal 


| Shopping 

Cart 
Data Partitioning 
{ordering 


EEKISEEKECEI 


Kemaye5 Idy 


Drawbacks 
« CAP Theorem: Data Consistency, Sacrifice Strong 
Consistency to Partition Tolerance 
e Cross-services Queries 
e Complex JOIN requires operations 
e Lack of Read-Write Database Separations 
, Distributed Transaction Management Mehmet Ozkaya 447 


Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Cross-Service Queries and Write Commands = m= He Fe] 
on Distributed Scaled Databases 


Considerations 

e Cross-services queries that retrieve data from 
several microservices ? 

e Separate read and write operations at scale ? 


Problems 

e Cross-Service Queries with Complex JOIN 
operations 

e Read and write operations at scale 

e Distributed Transaction Management 


Horizontal 


Data Partitioning 


= 
m 
N 
N 
> 
a 
m 
D 
2 
O 
A 
m 
a 


Aemayed dy 


Solutions 

e Microservices Data Query Pattern and Best = ji________ 2 L 
Practices 

e Materialized View Pattern 

e CQRS Design Pattern 

« Event Sourcing Pattern 
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Microservices Data 
Management - Commands 
and Queries 


Microservices Data Query Pattern and Best Practices 
Materialized View Pattern 

CQRS Design Pattern 

Event Sourcing Pattern 

Eventual Consistency Principle 

Mehmet Ozkaya 


450 


Architecture Design — Vertical Considerations 


—— Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Microservices Data Management - Main Topics 


Modular 
Monolithic 


Microservices 


Choosing Right Commands and 


Decomposition 


Communications 


Data Management 


Distributed 


Database Queries Transactions 
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Problem: Cross-Service Queries and Write Commands = m= He Fe] 
on Distributed Scaled Databases 


Considerations 

e Cross-services queries that retrieve data from 
several microservices ? 

e Separate read and write operations at scale ? 


Problems 

e Cross-Service Queries with Complex JOIN 
operations 

e Read and write operations at scale 

e Distributed Transaction Management 


Horizontal 


Data Partitioning 


= 
m 
N 
N 
> 
a 
m 
D 
2 
O 
A 
m 
a 


Aemayed dy 


Solutions 

e Microservices Data Query Pattern and Best = ji________ 2 L 
Practices 

e Materialized View Pattern 

e CQRS Design Pattern 

« Event Sourcing Pattern 
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Microservices Cross-Service Queries 


= Monolithic architectures, its very easy to query different 
entities, Querying data across multiple tables is 
straightforward. 


= WMicroservices architectures uses polyglot persistence, 
has different databases, need strategy to manage queries. 


= What if the client requests are visit more than one internal 
microservices ? 


= E-commerce application we have product, basket, 
discount, ordering microservices that needs to interact 
each other to perform customer use cases. 


= Integrations are querying each services data for 
aggregation or perform logics. 


1 


Getitem 
> 4— with > 
Details 


Client 
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How can we manage these cross-services queries ? 


= Direct HTTP Communication 
Not a good solution that makes coupling each microservices, f 
and loose power of microservices independency. Microservices Cross-Service Queries 


= Async Communication 
The best practice is reducing inter-service communication as 
much as possible and use async communication. Can't 
reduce these internal communications due to customer 
requirement. 


2 GetProduct 
1 


accumulate some data. 
Client 3 GetPrice 


= Those query request wait immediate response so we can't 
proceed with async communication. 


L] 
I 
I 
I 
I 
q 
U 
I 
U 
I 
I 
U 
n Getltem 
? À: : : 3 > 4— with 
= Client send query request to internal microservices to : Details 
U 
I 
I 
H 
i 
I 
I 
U 
l 
) 


= Transient errors, Network congestion or any overloaded 
microservice can result in long-running and failed operations. 


= Materialized View Pattern 


Reduce inter-service communication and provide sync 
response. Mehmet Ozkaya 455 


Microservices Cross-Service Queries - ee 
Example Use Case — Get Item with Details | rd 


Microservices Cross-Service Queries 


2 GetProduct 


1 
Getitem 
4— with —><ShoppingCart 
Details 
Client 3 GetPrice 
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Microservices Cross-Service Queries See 
Chain Queries — Get Order with All Details | rd 


Service-to-Service Communications - 
Chain Queries 


Client 


as ile se hl nd a ee ee ENER 
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Cross-Service Query Solutions in Microservices 


= Perform queries across microservices database level in 
data stores. 


= API Gateway patterns, we can solve cross-queries with 
applying Service Aggregator Pattern with create new 
Aggregator microservices. 


= How to solve problem with database level in data stores? 


= How get item info from the user's shopping cart with get 
data Catalog and Pricing microservice ? 


= Don’t want to interact with direct HTTP calls to get data 
from other catalog and pricing microservices. 


= Direct synchronous HTTP calls makes couple 
microservices together and reduce independency of 
microservices and makes chatty communications. 


1 


Getitem 
> 4— with > 
Details 


Client 
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Problem: Cross-Service Queries with Sync Response, ~ 


Decouple Way and Low Latency 


Problems 

e Cross-Service Queries with Complex JOINs 

e Return Sync Response with low latency 

e Provide loosely coupling with decouple services 
e Reduce inter-service communication 

SOLVE ALL PROBLEMS AT THE SAME TIME ! 


Considerations 

e Sync Communication: Use Service Aggregator Pattern 
but it increase coupling and latency. 

e Async Communication: Provide decoupling but query 
request are waiting immediate response. 


Solutions 
e Materialized View Pattern 
e CQRS Design Pattern 
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a 
J] 
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H 
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d 
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Service-to-Service Communications - 


Chain Queries 


Client 
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Materialized View Pattern 


= Why do we need Materialized View Pattern ? 


K command X i Write Database a 


= Mostly we design our systems with focusing on databases 
and tables for managing data size and data integrity. 


= How the data is stored ? Instead, how data is read ? 


= Negative effect on queries on our system. 
= Materialized View Pattern is store its own local and A í 


“1 Eventual 
Consistency 
denormalized copy of data in the microservice’s database.! crer GE 
: i : | Read Database 
= Shopping cart service should have table contains a 
e Materialized 
denormalized copy of the data from the product and Se 
pricing microservices. Lawn nn nnn nn nnn nn nn nn enn nn nn eee == + =~ --- ~~ ----- 
= Eliminates the need for expensive cross-service calls. Croat 
Le 
= Reduces coupling and improves reliability and response ShoppingCart ` 
time with reducing latency. 
Pricing 


= Can execute the entire operation with a single process. 
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Materialized View Pattern - 2 


= Also called this local copy of data as a Read Model. 


= Instead of querying the Product Catalog and Pricing 
services, it maintains its own local copy of that data. 


= Makes SC microservice is more resilient. 


K command X i Write Database a 


L] 
) 
L] 
) 
i] 
) 
i] 
) 
i] 
I 
L 
= ) 
Eventual i 
t 

1 

| 

t 

) 

| 

I 

' 

) 

I 

[] 

) 


= If one of the service is down, then the whole operation ! 
could be block or rollback. | A l 


Consistency 


í Read Database 


= With Materialized View Pattern, even if the Catalog and 
Pricing services are down, Shopping Cart can continue. 


Client 


= Broke the direct dependency of other microservices and Materialized 


View 
make faster the response time, help efficient- querying and. Lee eet ere Eeer 
improve application performance. Croat 

= Generate pre-populated views of data, more suitable Y fpf” 
ShoppingCart 
format for querying and provide good query performance. Ce 
Pricing 


= Includes joining tables and combining data entities and 


calculated columns and execute transforms. 
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= Views are disposible and can rebuilt from the source. á 


Considerations of Materialized View Pattern 


= With appying Materialized View Pattern, we have 
duplicated data into our system. oF eS Materialized View Pattern "` 1 


K command X i Write Database a 


= Duplicating data is not a anti-pattern, have strategically 
duplicating our data for microservice communications. 


= Only one service can be a data ownership. 
How and when the denormalized data will be updated ? | A > 


“1 Eventual 
Consistency 
= When the original data changes it should update into sc | Sien KKB 
microservices. Read Database 
= Need to synchronize the read models when the main oe 
service of data is updated. Le EELER 
= Solve with using asynchronous messaging and Croat 
publish/subscribe pattern. UN ice 
= Publish an event and consumes from the subscriber Y 
Pricing 


service to update its denormalized table. 


= Using a scheduled task, an external trigger, or a manual 
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CQRS - Command Query Responsibility Segregation 


= CQRS design pattern in order to avoid complex queries to 
get rid of inefficient joins. 


= Separates read and write operations with separating 
databases. 


= Commands: changing the state of data into application. 


= Queries: handling complex join operations and returning a 
result and don't change the state of data into application. 


Eventual 
(Consistency 


= Large-scaled microservices architectures needs to 


manage high-volume data requirements. 
Client 


= Single database for services can cause bottlenecks. 


= Uses both CQRS and Event Sourcing patterns to improve 
application performance. 


View 


= CQRS offers to separates read and write data that provide 
to maximize query performance and scalability. 
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CQRS - Read and Write Operations 


= Monolithic has single database is both working for 
complex join queries, and also perform CRUD operations. 


= When application goes more complex, this query and 
CRUD operations will become un-manageable situation. 


= Application required some query that needs to join more 
than 10 table, will lock the database due to latency of 
query computation. 


K commana X í Write Database Tapies 


= Performing CRUD operations need to make complex iis 
validations and process long business logics, will cause ES Sa 
SE 


to lock database operations. Client 


Á Read Database 


= Reading and writing database has different approaches, 
define different strategy. 


Materialized 
View 


=" «Separation of concerns» principles: separate reading 
database and the writing database with 2 database. 
= Read database uses No-SQL databases with denormalized data. 


= Write database uses Relational databases with fully normalized and 
supports strong data consistency. Mehmet Ozkaya 464 


CQRS - Read and Write Operations - 2 


= lf our application is mostly reading use cases and not writing so 
much, it is read-incentive application. 


= Read and write operations are asymmetrical and has very 
different performance and scale requirements. 


= To improve query performance, the read operation perform 
queries from a highly denormalized materialized views to avoic 
expensive repetitive table joins and table locks. 


= Write operation which is command operation, can perform 
commands into separate fully normalized relational database. 


= Supporting ACID transactions and strong data consistency. 


= Commands: task-based operations like "add item into shopping 
cart" or "checkout order". 


U 

| 

) 

I 

I 

i} 

I 

I 

I 

x ' 
i] 

I 

i Eventual i 

á Consistency 1 
7 ' 

I 

I 

4. > U 
I 

U 

I 

i} 

I 

I 

| 


View 


= Commands can be handle with message broker systems that 
provide to process commands in async way. 


= Queries: never modify the database, always return the JSON data 
with DTO objects. Mehmet Ozkaya 465 


CQRS - Synchronization with Read and Write DB 


= Keep sync both read and write databases. 


= Publishes an event that subscribe from Read ` CEET 
Database and update the read table accordingly. 


= Synchronization handles with async 
communication using message brokers. 


= This creates Eventual Consistency principle. 


Eventual 


= The Read database eventually synchronizes Consistency 


from the Write database. 


= Some lag in the process due to async Client 


communication with message brokers that applies 


publish/subscribe pattern. Materialized 


View 


= Welcome to Eventual consistency. 
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Benefits of CQRS 


= Scalability 
When we separate Read and Write databases, we can also 
scale these separate databases independently. Read 
databases follows denormalized data to perform complex join ------------------------------------------------ 


queries. 
K commana X d Write Database Tables 


i Eventual 
Consistency 


í Read Database 


=" |f application is read-incentive application, we can scale read 
database more then write database. 


= Query Performance 
The read database includes denormalized data that reduce to 
comlex and long-running join queries. Complex business 
logic goes into the write database. Improves application 
performance for all aspects. 


Client 


Materialized 
View 


= Maintability and Flexibility 
Flexibility of system that is better evolve over time and not 
affected to update commands and schema changes by 
separating read and write concerns into different databases. 


= Better implemented if we physically separate the read and Mehmet Ozkaya 
write databases. 
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Drawbacks of CQRS 


= Complexity 
CQRS makes your system more complex design. 
Strategically choose where we use and how we can separate 
read and write database. 


= Eventual Consistency 
The read data may be stay old and not-updated for a 
particular time. So the client could see old data even write 
database updated, it will take some time to update read data 
due to publish/subscribe mechanism. 


= We should embrace the Eventual Consistency when using 
CQRS, if your application required strong consistency than 
CQRS is not good to apply. 


Eventual 
(Consistency 


View 
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Best Practices for CQRS 


= Best practices to separate read and write database with 2 


database physically, nee eee eee eee ee ene eneeeeeee------ ~~ 


{ command) j Write Database a 


: Eventual 
(Consistency 


= Read-intensive that means reading more than writing, can 
define custom data schema to optimized for queries. 


= Materialized View Pattern is good example to implement 
reading databases. 


= Avoid complex joins and mappings with pre-defined fine- 
grained data for query operations. 

= Use different database for reading and writing database 
types. 


= Using No-SQL document database for reading and using 
Relational database for CRUD operations. 


Client 


View 
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Instagram Database Architecture with CQRS 


= Uses two database systems for different use cases: 
= Relational database - PostgreSQL and the other is No-SQL 


database — Cassandra. 
= Uses No-SQL Cassandra database for user stories. 


= Uses Relational PostgreSQL database for User Information 


: Other 
Django Services 
bio update. KZ 


| GP Come. user, media, friendship etc 


Read 


as Ce 
~~ 


Architecting a Scalable Technology Stack by Arunabh Das | Medium Replica 
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How to Sync Read and Write Databases in CQRS ? 


= Event-Driven Architecture, when something update in write 
database, publish an update event with using message 
broker systems, consume by the read database and sync 


data according to latest changes. oa a 


Lip Tables or 
fe Write Database| _ Event 
Sourcing 
I 
v 


= Creates a consistency issue, the data would not be reflected 
immediately due to async communication with message 
brokers. 


= «Eventual Consistency» The read database eventually 
synchronizes with the write database, and take some time to 
update read database in the async process. 


Eventual 
Consistency 


¢=- Eventbus 


= Take read database from replicas of write database. applying 
Materialized View Pattern can significantly increase query 
performance. 


Materialized 
View 


Read Database 


= Event Sourcing Pattern is the first pattern we should consider *--------- 7 rrr rrr rrr rrr rrr rrr rrr rr rrr n nrc nnn nnn 4 
to use with CQRS. 


= CQRS is using with "Event Sourcing Pattern" in Event-Driven 
Architectures. Mehmet Ozkaya 471 


Event Sourcing Pattern 


= Most applications saves data into databases with the re 
current state of the entity. l.e. user change the email 
address table, email field updated with the latest updated 
one. Always know the latest status of the data. 


Client 


d 
eme e e em e e e e el 


= In large-scaled architectures, frequent update database 
operations can negatively impact database performance, 
responsiveness, and limits of scalability. 


8 i 
consume : Materialized 


affects to data into Event Store database. And call all these a ME ii 
action as a event. Eventual 

= Instead of saving latest status of data into database, Event da Geen 
Sourcing pattern offers to save all events into database Dog ? „7 publish 


with sequential ordered of data events. 


= Event Sourcing pattern offers to persist each action that 
= This events database called Event Store. 
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' 

event Replay È 
Events e 

em mm mm mm zm em em em em em em wen vn om = wb Repla D K 
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Event Sourcing Pattern - 2 


= Instead of overriding the data into table, It create a new e 
record for each change to data, and it becomes sequential 
list of past events. 


= Event Store database become the source-of-truth of data.! client 


d 
eme e e em e e e e el 


= Sequential event list using for generating Materialized 
Views that represents final state of data to perform queries. 


= Event Store convert to read database with following the 
Materialized Views Pattern. 


A 1i 
consume : Materialized a 
event 1 View " 

' 


= Convert operation can handle by publish/subscribe pattern Been i 
with publish event with message broker systems. ` [vente (| Consistency 4 
= Event list gives ability to replay events at given certain ieee publish 


timestamp. we. Events no ! 
= Itis able to re-build latest status of data with replaying 


events. E Nd Rk ot Nan ee ben Cee L A ee 
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CQRS with Event Sourcing Pattern 


= CQRS pattern is mostly using with the Event Sourcing 
pattern. 


= Store events into the write database; source-of-truth 


events database. Client 


d 
EES ow ol 


= Read database of CQRS pattern provides materialized 
views of the data with denormalized tables. 


consume A Materialized ii 
event ı View " 
i] 


= Materialized views read database consumes events 
from write database convert them into denormalized 


views. e 
Eventual H 
age H 8 H 
= The writing database is never save status of data only i [events ( Consistency 1 
events actions are stored. Event Sek 
Sourcing © 


= Store history of data and able to reply any point of time 
in order to re-generate status of data. 


" 
' 

' 

event Replay a 
Events e 

ze zm zm mm mm mm em em em em wm wen e em ze wb Repla D : 
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= System can increased query performance and scale EE 
databases independently. 
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CQRS with Event Sourcing Pattern 


e mm em em em em em em wm wm wm wl 
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Eventual Consistency Principle 


= CQRS with Event Sourcing Pattern leads Eventual 
Consistency. 


= Eventual Consistency is especially used for systems that 


prefer high availability to strong consistency. = 


d 
EES ow ol 


= The system will become consistent after a certain time. 


= We called this latency is a Eventual Consistency 
Principle and offers to be consistent after a certain time. 


à H 
consume A Materialized ii 
event ı View " 

i] 


= There are 2 type of "Consistency Level": 


= Strict Consistency: When we save data, the data should Dien I 
affect and seen immediately for every client. 7 
i l Event "publish 
= Eventual Consistency: When we write any data, it will Sourcing i 


take some time for clients reading the data. 


" 
' 

' 

event Replay a 
Events í 

ee ee Repla D : 
' 

' 
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Eventual Consistency Principle - 2 


CQRS Design Pattern and Event Sourcing patterns: 


1. When user perform any action into application, this will 
save actions as a event into event store. 


2. Data will convert to Reading database with following the 
publish/subscribe pattern with using message brokers. 


3. Data will be denormalized into materialized view 
database for querying from the application. 


We call this process is a Eventual Consistency Principle. 


Client 


d 
EES ow ol 


consume A Materialized ii 
event ı View " 
i] 


u 
Eventual : 
g Consistency 
7 
I 


H 
i 
p " 
„7 publish + 
event Replay i 
Eé Events e 
eme eess desch Replay ' 

i 

' 
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Event 
Sourcing 


Microservices Data Patterns and Principles 


= Materialized View Pattern 
= CQRS Design Pattern 
= Event Sourcing Pattern 


= Eventual Consistency Principle 


consume } Materialized "i 
event ı View H 


" 
Eventual : 
Consistency 


7 H 

a a 

s U 

event „7 publish ' 
Sourcing event Replay ! 
----------- EVENİS 1 

-=--> Replay i 

i 
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Instagram System Architecture 


= Instagram is an application that is used all over the world with 
under heavy traffic. 


= Visited by 500 million people, Almost 100 million photos are 
shared, 400 million stories. 


= Huge amount of data and interactions that need to handle with 
the strong architecture of Instagram. 


= Have many servers, data center to spread to many parts of the 
world. 


= Network delays can cause wait for a long time for the user 
sending requests. 


= Instagram has a Data Center in many parts of the world. 
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Instagram System Architecture - 2 


= Instagram uses two database systems: PostgreSQL, 
Cassandra. 


= Designed that users can communicate with the nearest 


data center and receive quick responses to requests. 


eer Cassandra 
= CAP Theorem: either Availability or Consistency must be 


selected in a distributed system. 


PostgreSQL 
Other 


Services 


= Instagram decided that Availability was more important 
to them and thought that Eventual Consistency would beli C DGE 
sufficient. 


RabbitMQ 


= Polygot Persistence: uses relational PostgreSQL and 
No-SQL Cassandra databases. 


It 


= CQRS Design Pattern: separated read-incentive use 
cases with Cassandra No-SQL database which uses is 
user stories. 


= Eventual Consistency: Updates reflect with lag, decide 


the be Availability every time. Mehmet Ozkaya 480 


Instagram Database Architecture 


= Instagram uses two database systems: PostgreSQL, 
Cassandra. 


= Why use PostgreSQL relational database ? 
PostgreSQL has a "Master-Slave" architecture. 
PostgreSQL on Instagram is configured to have one 
Master and multiple read-only Slaves. 


= Ifthe transaction causes a change in the data like update 
or delete user info, that request must be forwarded to the 
Master. 


= Any update that occurs in the master is sent from the 
master to the slaves, ensuring the synchronization of the 
databases. 


= What data does Instagram keep in PostgreSQL? 


user information, user relations (friendship), tags, aloums, 


photos and videos. 


Polyglot Persistence 


| Cassandra 
PostgreSQL 
Di Other 
ango 
| memcache | J g Services 


WÉI user, media, friendship etc 


Read 
Eea `" Ce 
oe 


Architecting a Scalable Technology Stack | | by Arunabh Das | Medium 
eplica 
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Instagram Database Architecture - 2 


= Why use Cassandra No-SQL database ? 


Cassandra has a Master-Master architecture we can call | Cassandra 
Master-less architecture. Cassandras communication is 
i-directi PostgreSQL 
multi-directional between Data Centers of Instagram. ae 
e What data does Instagram keep in Cassandra ? memcache | Django Services 
User feed, Counters, Messaging 
= The user flow of Instagram is includes the last posts of the 


people that user follows, resolved by making use of Polyglot Persistence 


Cassandra. WÉI user, media, friendship etc 


= Why was Cassandra chosen ? 
Cassandra has an auto-sharding feature like many NoSQL Read 


databases. Sharding helps keep data divided among 
nodes. Write 


= Disk usage of the servers are optimized and the workload os 
between the nodes is easily distributed. 
Architecting a Scalable Technology Stack | | by Arunabh Das | Medium 
| Replica | 
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Before Design — What we have in our design toolbox ? - Data 


Architectures Patterns&Principles Microservices Data 


Microservices e 
Architecture 


The Database-per- 
Service Pattern ! 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube ` 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices Data 
Management Patterns 


Choosing Database 


The Shared Database Anti- e 
pattern 


Relational and NoSQL 
Databases 


CAP Theorem—Consistency, 
Availability, Partition 
Tolerance 


Data Partitioning: 
Horizontal, Vertical and 
Functional Data Partitioning 


Database Sharding Pattern 


Microservices Data 
Commands&Queries 


Materialized View Pattern 


CQRS Design Pattern 


Event Sourcing Pattern 


Eventual Consistency 
Principle 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an orde 


List my old orders and 
order items history 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 
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Independent 


Design: Microservices Architecture with CQRS, 
Event Sourcing, Eventual Consistency 


Microservices with CQRS, Event Sourcing 


| Product ` No-SQL Read 
Shopping Database 
| Cart consume 


r d Eventual 
i f Consistenc 
uy 1 Ordering 
omat EA | 
ii a pw TE er ff ff ff EE i 
en I! publish 
7 Relational \. RDBMS Së 
i 
Pee 


Write Database 
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Kema}e5d |dV 
agJyOŅNg JOVSSIJWN 
wen em em em em em em ER ER ER ER ER ER ER ER E E E em em J 


Adapt: Microservice Architecture with CQRS, 
Event Sourcing, Eventual Consistency 


API Gateways 

e Kong Gateway 

e Express Gateway 

, Amazon AWS API Gateway 
Message Brokers 


WEE E 
Frontend SPAs Client Apps! i Microservices with CQRS, Event Sourcing 
e Angular 
e Vue i No-SQL Read 
a 
. React ! Database 
H 
H 
II 
H 


Kema}e5 |dV 
EEKISCCKEIDKECEId 


| ordering 


ve wm em em em em em em ee 8888888 em em vm oo wm ~~ = el 


H 
Gren : "ET Fien 
eener SNS e hisani STE 
' i Write Database 
Backend Microservices SS Seo>e VEER 
, Java — Spring Boot READ DB - No-SQL Database WRITE DB - Relational Database 
, Net — Asp.net e Cassandra — NoSQL Peer-to-Peer . PostgreSQL 


e MongoDB — NoSQL Document DB . SOL Server 
e Redis — NoSQL Key-Value Pair 
e Amazon DynamoDB, Azure CosmosDB 


e JS — NodeJS 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservice Architecture with CQRS, 
Event Sourcing, Eventual Consistency 


Benefits 
Better Scalability, Separate Read and Write Peery en Ce ee a 
databases scales independently. i 
) 
Increased Query Performance, read database ! 
denormalized data reduce to complex and long- 
running join queries. , 
Increased Maintability and Flexibility, system 
: 
| 
i 
1 
| 
) 
) 
1 
) 
i] 


No-SQL Read 
Database 


consume 
event 


Eventual 
Consistenc 


better evolve over time 
Distributed Horizontally Scaled Databases that 
ready for Kubernetes Deployments 


Aemayed IdV 
yIyOY9 JƏYSSIN 


-- 
--" 
-- 


“MUL publish 
Relational RDBMS event 


Write Database 


"see se E ER ER ER EE ER ER ER E E ER E em em em em em em wn vm el 


Drawbacks E 
« Increased Complexity, CQRS makes your system 

more complex design. 
e Eventual Consistency 


e Distributed Transaction Management 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Manage Consistency Across Microservices =en = he h= 
in Distributed Transactions 


Considerations 
e Distributed Transactions that required to visit several microservices ? 
e Consistency across multiple microservices VE er E e a a 


, , i Client Apps , 
« Rollback transaction and run compensating steps ? ! 


No-SQL Read 
Database 


Shopping 
Problems EEN 
e Distributed Transaction Management 
e Rollback Transaction on Distributed Environment 


e Run Compensate Steps if one of service fail 


consume 
event 


Eventual 
Consistenc 


AeEMd}e5 |dV 
YayvOu" I9YSSIN 


~= 


UMM, publish 
Relational RDBMS event 


Write Database 


-- 
- 
--" 
- 


Solutions 
e Microservices Distributed Transaction Management 
Pattern and Best Practices 

e Saga Pattern for Distributed Transactions 

, Transactional Outbox Pattern 

e Compensating Transaction pattern 

e CDC - Change Data Capture 


em em ep ep ep = = z z= Se SS Ss SS SS Se e e ep wm en en em 
we wm em em em em em em em ER ER ER EE E E em em pm pm vm pm em e wm wm wm el 
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Microservices Distributed 
Transactions 


Saga Pattern for Distributed Transactions - Choreography and Orchestration 
Transactional Outbox Pattern 

Compensating Transaction pattern 

Dual-Write Problem 

CDC - Change Data Capture 
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Microservices Data Management - Main Topics 


Modular 


Microservices 


Monolithic 


Decomposition 


Communications 


Data Management 


Choosing Right 


Database 


Commands and 
Queries 


Distributed 
Transactions 


e Polyglot persistence 


e The API Composition 


e The Database-per-Service wv The CQRS pattern 
e The Shared Database Anti- e The Event Sourcing 


Pattern 


Pattern 


The Saga Pattern 
Transactional Outbox 
Compensating Transactions 
CDC - Change Data Capture 
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Architecture Design — Vertical Considerations 


‘costumed Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 
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Problem: Manage Consistency Across Microservices =en = he h= 
in Distributed Transactions 


Considerations 
e Distributed Transactions that required to visit several microservices ? 
e Consistency across multiple microservices VE er E e a a 


, , i Client Apps , 
« Rollback transaction and run compensating steps ? ! 


No-SQL Read 
Database 


Shopping 
Problems EEN 
e Distributed Transaction Management 
e Rollback Transaction on Distributed Environment 


e Run Compensate Steps if one of service fail 


consume 
event 


Eventual 
Consistenc 


AeEMd}e5 |dV 
YayvOu" I9YSSIN 


~= 


UMM, publish 
Relational RDBMS event 


Write Database 


-- 
- 
--" 
- 


Solutions 
e Microservices Distributed Transaction Management 
Pattern and Best Practices 

e Saga Pattern for Distributed Transactions 

, Transactional Outbox Pattern 

e Compensating Transaction pattern 

e CDC - Change Data Capture 


em em ep ep ep = = z z= Se SS Ss SS SS Se e e ep wm en en em 
we wm em em em em em em em ER ER ER EE E E em em pm pm vm pm em e wm wm wm el 
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Transaction Fundamentals and ACID Principles 


= Transaction is the context of database operations that 
should act to be single unit of work. 


= Should fully complete the operation or if something fail, it 
should rollback the whole operation and go back to 


consistent state. 
= ACID - Atomicity, Consistency, Isolation, and Durability "a be a} D) 


= If one change fails on database, the whole transaction is Atomicity Consistency | Isolation Durability 
going to fail, and the database should remain in the 
previous state. 


= Relational Databases are providing ACID principles to 
ensure Data Consistency. 


= If you need strong consistency, its good to choose 
Relational Databases. 
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ACID Principles 


= ACID - Atomicity, Consistency, Isolation, and Durability 


= Atomicity 
All operations are executed successfully or everything fails 
and rollback together. 


= Consistency 


The data in the database is kept in a valid and consistent "a bei a} D) 


state, after any operations on data. 


Atomicity Consistency Isolation Durability 


= Isolation 
Separated transactions running concurrently and they can not 
interfere with each other. 


= Durability 
After a transaction is committed, the changes are stored 
durably, for example persisted in a database server. 


= Example: Money transfer transaction. 
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Transaction Management of Monolithic Architecture 


= Transaction management in Monolith architecture is quite easy compared 
to Microservice Architecture. Many frameworks contains mechanism for 
transaction management. 


= These mechanism have a single database of the whole application. function place order() 
They are developed for scenarios where all transactions are running ona do payment 


single context. 
= Simply commit and rollback operations with these mechanism in monolith decrease_stock 


architectures. Send shipment 
= Transactions operated in the transaction scope are kept in memory generate_bill 
without writing to the database until they are committed, and if a Rollback update order 


is made at any time, all transactions in the scope are deleted from memory 
and the transaction is canceled. 


= When Commit is written to the database, the transaction is completed 
successfully. 
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Microservices Distributed Transactions 


= How to perform transactional operations across microservices and 
which patterns we should apply ? 


= Querying data and run complex join queries across microservices is 
not easy but implement transactional operations across microservices 
i S m O re CO m p | ex : Microservices Distributed Transactions 


r í 7 Order Payment | Inventory | Shipping 
= We should handle distributed transaction managements on 


A r s i a Create Validate Update 
microservices by manually implementing some patterns and practices|\ order Payment Inventory 
= Distributed transaction managements on microservices, mostly 


r . ï Complete 
working with eventual consistency. 


= Microservices has its own database and communicates each other with 
exposing APIs, it makes harder to perform end-to-end business 
cases across multiple microservices when trying to keep data 
consistency. 


= How to achieve consistency across multiple microservices ? 
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How to achieve Data Consistency 
across multiple microservices ? 


eFeea eau ges See eee SO SO OS SBGeenseenuoouwoae2ereece=— |,» ` mmm mm mm mm mm mm em mm SB mm em em mm wm em wm em em eee em mm wm em ee wm mm mm em mm mm mm mm mm mm mm mm mm mm mm mm mm 


Additem into Shopping Cart Product Price Changed 


i d 
' 1 
I N I i 
H 
H, q ' 
2 GetProduct i ` ' 7 DE, ' 
i 
: D icochanged § 
ricechange 
iNi http Event- g ; 
KS reqire based asynchronous 1 
P Ir communication with ; 
= Client Eventual Consistency 1 
; J 1 U 
Client 1 H: 1 
o! i 
A Shopping i 
AR Cart 
dl WI i 
I U I i 
em wm wm em em em em em em em em em em em em ee ee em e sm mm sm mm sp a sm em em mm em mm mm wm wn sl H Lea em wn wm e em e e em em em em em em em em em wm em em em em em em wm em em em om em em e e e wm wm wm vm wm em wm «= = 
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How to achieve Data Consistency 
across multiple microservices ? - 2 


CAP Theorem: need to sacrifice ACID strong consistency to the 


High Availability and Partition Tolerance. 


Most microservice-based applications are choosing high 
availability and high scalability against to strong consistency. 


Microservices sacrifice strong consistency and follow with eventual 
consistency to get benefits of microservices availability and scalability. 


NoSQL database are mostly using in microservices because they can 
easily and horizontally scale in distributed environments. 


Must use asynchronous event-driven communication and 
publish/subscribe pattern following to eventual consistency. 


When product price updated, Product service publish changes with '-----------------------*ss====7------------: 
Product price changed event to the Event Bus, that subscribe by 
ShoppingCart service with following eventual consistency principle. 


This process should be resilient and idempotent for redundant event 


processing; Microservices Resillience. 


Event- 
based asynchronous 
communication with 

Eventual Consistency 


ai Shopping 
Cart 


e zm zm mm em em em em em em eee mm em eee em em em em am wm = sl 
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Bounded Context Pattern (Domain-Driven Design) 


= DDD - Bounded Context Pattern which is one of the main Dë? 
pattern that we mainly use when decomposing 
microservices. 


Optimal Acquisition 
Context 


= Domains are require high cooperation and have a certain 
complexity by nature are called collaborative domains. 


= DDD has 2 phases, Strategic and Tactical DDD. 


= Strategic DDD, we define the large-scale model of the 
system, defining to the business rules that allow designing 
loosely coupling units and the context map between them. 


Inventory 
(Supporting) 


Inventory Context 


a 
I'm a 


Resource 
Planning 
(Generic) 


Mapping 
Context 
(External) 


= Tactical DDD focuses on implementation and provides design 
patterns that we can use to build the software 
implementation. 


= Include concepts such as entity, aggregate, value object, 
repository, and domain service. 
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Bounded Context Pattern (Domain-Driven Design)-2 


= DDD domain defines its own common language and divides 
boundaries into specific, independent components. Common 
language is called ubiquitous language, and independent Lu Bang "EES wg 
units are called bounded context. 7 


Sales Context 


= DDD is solving a complex problem is to break the problem into 
smaller parts and focus on smaller problems that are relatively 
easy. \ 


= A complex domain may contain sub domains. And some of 
sub domains can combine and grouping with each other for 
common rules and responsibilities. 


= Bounded Context is the grouping of closely related scopes tha 


we can say logical boundaries. Contexts and being explicit about their interrelationships. 


= Bounded context is the logical boundary that represents the 
smaller problem particles of the complex domain that are self- 
consistent and as independent as possible. 


http://martinfowler.com/bliki/BoundedContext.html 
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DDD deals with large models by dividing them into different Bounded 


Identify Bounded Context Boundaries 
for Each Microservices 


= Identify the Bounded Contexts by talking to the domain 
experts and using some clues. 


= Once defined the Bounded Contexts, iterate design, those are 
not immutable. 


Customers Orders 


= Reshape your Bounded Contexts by talking to the domain 
experts and consider refactoring's with the changing 
conditions. 


= Its crucial to discuss with domain experts to defining domains 


and sub domains. Payment 


Shopping Cart 


= Evaluate Bounded Context with the domain experts will help 
you identify to microservices. 


same data but naming differently due to domain experts areas. L--== =I IIIT eo eee eee eee 


= Sub domains inside of the Bounded Context are representing 


= Should discuss several domain experts for their expertise 
areas. 
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Microservices Transactional Boundaries 


= We have several Bounded Context and Microservices for our e- 
commerce application: 


= Customer-User, Product, Shopping Cart, Discount 


= Ordering, Payment, Inventory, Shipment, Notification 
Order fullfilment 
E2E use case 
Transactional 


= Some of these bounded context need to organize and 
communicate each other to perform End-to-end business use 
cases. 


= After identifying Bounded Contexts and microservices, should 
also identify our microservices transactional boundaries. 


= What are Microservices Transactional Boundaries ? 
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What are Microservices Transactional Boundaries ? 


= Transactional Boundaries are smallest unit of atomicity that 
need to provide consistency between services. 


= In distributed architecture we can't provide ACID principles. Microservices Transactional Boundaries 


= Should define Transactional Boundaries and perform EZE 


use cases to try to keep data consistency. Order fullfilment 
E2E use case 


= Use asynchronous event-driven communication and CERS REN 


publish/subscribe pattern following to eventual consistency. 


= Not enough for complex and long EZE business case that 
required to visit more that 5 microservices in a distributed 
environment. 


= WMicroservices Transactional Boundaries is identify minimum 
smallest unit of atomicity use cases and design 
communication between those boundaries. 


Mehmet Ozkaya 504 


Customer checkout Shopping Cart and 
start Ordering process 


Order created into Order microservices 
and start E2E fulfillment process 


Payment should be validate and done 


Deduct items into Inventory with update 
Inventory Service 


Shipping to Customer Address manages 
from Shipment Service 


Notification send to Customer from 
Notification Service 


Microservices Transactional Boundaries 


Order fullfilment 
E2E use case 
Transactional 
Boundaries 


Notification 
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Microservices Transactional Boundaries 
Order Fulfillment - Success 


Microservices Distributed Transactions 


Validate ` Update 
Payment Inventory 


Complete 
Order 
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Microservices Transactional Boundaries 
Order Fulfillment - Rollback 


Create Validate \ 
Order Payment 


Cancel / Cancel Rollback 
Payment Inventory 


Rollback 
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Saga Pattern for Distributed Transactions 


= Saga design pattern is provide to manage data consistency across 
microservices in distributed transaction cases. 


= Saga offers to create a set of transactions that update 
microservices sequentially, and publish events to trigger the next 
transaction for the next microservices. SE 


= If one of the step is failed, than saga patterns trigger to rollback (_oraer Il ES ] 
transactions, do reverse operations with publishing rollback 


. i . . Payment Inventory 
events to previous microservices. td 
= Publish/subscribe pattern with brokers or API composition. 
= SAGA pattern manage long-running transactions that involve 


multiple microservices which is a series of local transactions that 
work together to achieve E2E use case. 


= Useful in distributed systems, where multiple microservices need to 
coordinate their actions. 


= Ensure that the overall transaction is either completed 
successfully, or is rolled back to its initial state. (compensating 
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Saga Pattern for Distributed Transactions - 2 


= Saga pattern provides transaction management with using a sequence of local transactions of 
microservices. And grouping these local transactions and sequentially invoking one by one. 


= Each local transaction updates the database and publishes an event to trigger the next local transaction. 
If one of the step is failed, than saga patterns trigger to rollback transactions. 


SAGA Pattern 


Create d Validate Update 
Order . Payment Inventory 3 


Cancel Cancel Rollback ` 
Order Payment Invento 


Rollback 
Complete 
Order ` 


5 
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Types of Saga Implementation 


= There are two type of saga implementation ways: 


= Choreography-based SAGA Implementation 


= Orchestration-based SAGA Implementation 


d Validate 
_ Payment 


Cancel 
Payment 


Complete 
Order 


SAGA Pattern 


Update 
Inventory 


Rollback ` 
, Inventory 


Rollback 


5 
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Choreography-based SAGA Implementation 


= Each microservice communicates with the other microservices by exchanging events using a 
message broker. 


= Event-based approach allows for a more decentralized and flexible way to implement the SAGA 
pattern, as each microservice can publish to events to the others in real-time. 


= Choreography provides to coordinate sagas with applying publish-subscribe principles. 


= Each microservices run its own local transaction, publishes events to message broker system and 
trigger local transactions in other microservices. 


Choreography way of Saga pattern 


Validate Update 
Payment Inventory 


Complete \_ : 
Message Broker S 
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Order Fullfilment with 
Choreography-based SAGA Implementation 


The customer places an order on the e-commerce application and provides their payment information. 
The order microservice begins a local transaction and publishes an event to the message broker. 


The inventory microservice listens for the event published by the order microservice and, it begins a local 
transaction and reserves the items in the customer's order. 


The inventory microservice publishes an event to the message broker, the items were reserved successfully. 


The payment microservice listens for the event published by the inventory microservice and it charges the 
customer's payment method and commits its own local transaction. 


Choreography way of Saga ec 


Yi < > Message Broker S 
Mehmet Ozkaya 512 


Order Fullfilment Rollback with 


Choreography-based SAGA Implementation 


SAGA pattern provides a way to roll back the changes made by each microservice. 


If the Inventory microservice encountered an error while reserving the items in the customer's order, it could 
publish a failure event to the message broker. 


Order fulfillment microservice would then execute a compensating transaction to undo the charges to the 
customer's payment method and cancel the order. 


Choreography way of Saga pattern 


Validate 
Payment 


Complete 
Order 
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Benefits of Choreography-based SAGA 


= Decentralized and flexible 
By using an event-based approach, each microservice can react to events published with the others to 
coordinate their actions. This allows for a more decentralized and flexible approach to implementing the 
SAGA pattern. 


= Decouple direct dependency of microservices when managing transactions. 


= Avoid Single Point of Failure 
Since there is no orchestrator, responsibilities are distributed across the saga participants. 


= Simple workflows 
This way is good for simple workflows, if they don't require too much microservices transaction steps. 
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Drawbacks of Choreography-based SAGA 


= More complex to manage 
Each microservice communicates via events with the others, the choreography-based approach can be 
more complex to manage and may require more coordination among the microservices. 


= SAGA workflow become confusing when adding new steps into flow. 


= Cyclic Event Consume Risk 
There's a Cyclic Event Consume Risk dependency between saga participants because they have to 
consume each other's commands. 


= Result 
Implementing the SAGA pattern will depend on the specific needs and constraints of the distributed system. 
It may be a good fit for some systems, but may not be suitable for others. 


= Choreography-based implementation of SAGA is good for simple workflows if they don't require too much 
micorservices transaction steps. 
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Orchestration-based SAGA Implementation 


= Orchestration-based SAGA pattern involves using a central orchestrator service to coordinate and 
manage the individual sagas or microservices that make up a transaction. 


= The orchestrator is responsible for initiating the transaction and ensuring that each saga performs its 
step in the correct order. 


= If any of the sagas fail to complete their step, the orchestrator can use the compensating transactions 
to roll back the changes and restore the system to its original state. 


= Orchestration provides to coordinate sagas with a centralized controller microservice that orchestrate 
the saga workflow and invoke to execute local microservices transactions in sequentially. 


Notification 


Orchestration way of Saga pattern 


VD. CEN A) BD. 


Validate 
Payment / 
Complete \_ | / 
Order / í Orchestration 
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Orchestration way of Saga pattern - Rollback 


Create Validate 
Order Payment 


7 


V 
Cancel . 
Order 
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Benefits and Drawback of 


Orchestration-based SAGA Implementation 


Benefits 

= Provides a clear and centralized point of control for managing transactions. 

= Make it easier to understand and debug the system, and to add new transactions or modify existing ones. 
Drawbacks 


= The orchestrator can also become a single point of failure, and if it goes down, the entire system may be 
unable to complete transactions. 


= The orchestrator can become a bottleneck if the system is heavily loaded, as all transactions must go 
through it. 


Result 


= It can be a useful approach for managing transactions in a distributed system, but it is important to carefully 
consider the trade-offs and potential drawbacks. 


= Orchestration way is good for complex workflows which includes lots of steps. 


= But this makes single point-of-failure with centralized controller microservices and need implementation of 


complex steps. 
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Compensating Transaction Pattern 


= Compensating Transaction pattern is a rollback process of SAGA 
Pattern. 


= Compensating Transaction pattern is provides to reverse the steps 
for a previously executed transaction. 


Compensating Transaction Pattern 


= |n microservice architectures where multiple services may be [order] ( Payment 1 (inventory | {shipping 


involved in a distributed transaction, if any of the services fail to Update 
Order 


i e a Payment Invento 4 SEH? Notify 
complete their part of the transaction, the effects of the entire ry 
transaction need to be undone. LULL, 
Order 


Payment \ Inventory 
j , 


= The steps in a compensating transaction should undo the effects of | 
the steps in the original operation. 


= Compensating transaction is also an eventually consistent operation 
and it could be fail. 


= The system should be able to resume the compensating 
transaction at the point of failure and continue. 


= The steps in a compensating transaction should be defined as 


idempotent commands. Mehmet Ozkaya 519 


Ecommerce Order Fullfilment -HEH He 
Compensating Transaction Pattern | rd 


= Customer places an order on the e-commerce application 


Compensating Transaction Pattern 


Validate Update 
Payment Inventory 


Rollback 
LLL 


/ Complete 
Order 
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Problem: Dual Write Problem 


When application needs to change data in two different 
systems, i.e. a database and a message queue, if one of the 
writes fails, it can result in inconsistent data. 

Happens when you use a local transaction with each of the 
external systems operations. 

Le app needs to persist data in the database and send a 
message to Kafka for notifying other systems. 

If one of these two operations fails, the data will be 


inconsistent data and these two systems becomes inconsistent. 


Problems 

e Data loss or corruption. 

e Difficult to resolve without proper error handling and recovery 
mechanisms. 

e Dual writes can be hard to detect and fix. 


Dual Write Problem 


2- Publish 
event 


1- Write Order 
Tab 


le | 
= A A 
ës 
| Order 
Table 


Order Database 
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Example of Dual-write problem: Create Order 


1- Change data in Order database with creating new record 
2- Send an order_created event to the EventBus like Apache Kafka. 


Dual Write Problem 


User = i 
1- Write Order = PODIBN 
event 


Table 


Order Database 


Run Transactions 
1,2 or 
2,1 


Both becomes 
dual writes 
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How to avoid dual write problems in microservices ? l =a 


Monolith applications use the 2 phase commit protocol. 

It splits the commit process of the transaction into 2 steps and 
ensures the ACID principles for all systems. 

Can't use 2-phase commit transactions when building 
microservices. 

These transactions require locks and don’t scale well. 

Need all systems to be up and running at the same time. 


Solutions — - 
, Transactional Outbox Pattern 
, CDC - Change Data Capture LPB 


Order Database 


Best Practice 

, Use Red Hat Apache Kafka and CDC using Debezium in event- 
driven applications. 

e Use New databases like CockroachDB which has built-in 
Change Data Capture feature. 
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Transactional Outbox Pattern 


= The idea is to have an “Outbox” table in the microservice’s 
database. It provides to publish events reliably. 


= Dual write problem happens when application needs to change 
data in two different systems. 


= Instead of sending the data to two separate locations, send a 
single transaction that will store two separate copies of the dati 
on the database. 


= One copy is stored in the relevant database table, and the other 
copy is stored in an outbox table that will publish to event bus. 


Order Database 


= When API publishes event messages, it doesn’t directly send 
them, Instead, the messages are persisted in a database table. 


= After that, a job publish events to message broker system in 
predefined time intervals. 


= Events are not written directly to a event bus, it is written toa 
table in the "Outbox" role of the service. 
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Transactional Outbox Pattern - 2 


= Transaction performed before the event and the event written to the outbox table are part of the same 
transaction. 


= When a new order is added to the system, the process of adding the order and writing the Order_Created 
event to the Outbox table is done in the same transaction to ensure the event is saved to the database. 


= |f one of the process is fail, this will rollback the whole operations with following ACID principles. 


= The second step is to receive these events written to the Outbox table by an independent service and write 
them to the Event bus. Another service listen and polls the Outbox table records and publish events. 
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Transactional Outbox Pattern in Microservices 


= WMicroservice provides an outbox table within its database. 
Outbox table will include all the events. 


= There will be a CDC (change data capture) plugin that 
reads the commit log of the outbox table and publish the 
events to the relevant queue. 


= It provides that messages are reliably delivered from a 
microservice to another microservice even if the 
transaction that triggered the message fails. 


= Itinvolves storing the message in a local "Outbox" table 
within the microservice, that message sent to the consumer 
after the transaction is committed. 


Order Database 


= Outbox pattern can be used to ensure that messages are 
delivered consistently, even if the microservice that sent the 
message is unavailable or experiencing errors. 


= Useful for communicating important information or updates 


between services. 
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Customer Places an Order Use Case - FE 
Transactional Outbox pattern in Microservices Oo r 


Transactional Outbox Pattern 


Publish 


Order Database 
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Why Use Outbox Pattern ? 


= When working with critical data that need to consistent 
and need to accurate to catch all requests. 


= When the database update and sending of the message 
should be atomic to make sure data consistency. 


= For example the order sale transactions, because they are 
about financial business. Thus, the calculations must be 
correct 100%. 


= To access this accuracy, must be sure that our system is not 
losing any event messages. 


= The Outbox Pattern should be applied this kind of cases. SE 
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Problem: Listen and Polling Outbox Table eT 


, Creating new order record into order table and creating new 
order_created event into outbox table are in the same transactions. 

, Another service listen and polls the outbox table records and publish 
events into separate processes. 

e The current architecture required additional microservices that listen and 
polls records from the outbox table. 


Problems 

e Reduces the performance and error-prone operations. 

e Time is wasted during Polling, wasted resources. 

e Consuming system resource unnecessary pull requests. 
e Come with a latency overhead, reach system limitations. 
e Can cause additional Dual-write problem. Order Database 


How solve these problems when applied outbox pattern ? 
e CDC - Change Data Capture with Outbox Pattern. 
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CDC - Change Data Capture 


= Change Data Capture (CDC) is a technology that captures 
insert, update, and delete activity on a database. 


= CDC typically works by continuously monitoring the 
transaction log of a database for changes, and then 
extracting and propagating those changes to the target 
system. 


= This allows the target system to stay up-to-date with the 
source system in near real-time, instead of relying on batch- 
based data synchronization processes. 


= CDC can be used in replicating data between databases, 
synchronizing data between systems in a microservices 
architecture, and enabling real-time data analytics. 


= CDC is a way to track changes that happen to data ina 
database that captures insert, update, and delete activity 
and makes this information available to other systems. 


= This allows those systems to stay up-to-date with the data in 
the database in real-time. 


oie) 


CDC - Change Data Capture 
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CDC - Change Data Capture with Outbox Pattern 


= Outbox pattern is ensuring data changes made by a 
microservice are eventually propagated to other 
microservices. 


= Whenever a microservice updates data in its database, it also 
i . . CDC - Change Data Capture 
writes a record to the outbox table with the details of the ; e 
change. | 


= CDC can then be used to monitor the outbox table for new 
records, extract the data changes that propagated to the 
target microservices to be kept up-to-date with the data. 


= Using CDC with the Outbox pattern allows microservices to 
decouple their data updates from the process of 
propagating those updates to other microservices. 


= This can make it easier to scale and maintain a 
microservices architecture. 


= Each microservice can focus on its own data updates and 


let CDC handle the synchronization of data between 
services. Mehmet Ozkaya 531 


CDC - Change Data Capture with Outbox Pattern 
E-commerce Create Order Use Case 


CDC - Change Data Capture with Outbox 
Create Order Use Case 
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CDC - Change Data Capture with Outbox Pattern 
E-commerce Create Order Use Case 


Order 
Service 


ea: 
ane : Router = 


Debezium: 


Id AggregateType Aggregateld Type Payload 


8af8 |Order 456 OrderDetailCanceled |{"id": 456, ... } 
890b |Customer 189 InvoiceCreated tele TASKS), ns 3} 


Outbox Table 


https://debezium.io/blog/2019/02/19/reliable-microservices-data-exchange-with-the-outbox-pattern/ M 
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CockroachDB for CDC and Outbox Pattern 


= CockroachDB is a distributed database management 
system that is designed to be scalable, resilient, and easy to 


use. range ieda —" RR BE Katka 
= Cockroach cluster, which is a group of database nodes ost 

that work together to form a single, highly available database. Le be 7 
= Ability to scale horizontally by adding more nodes to the | (o> OOSOOR 

cluster as the workload increases. me aa 
= CockroachDB also has strong support for data consistency KH í al 

and durability, with features such as multi-active availability n 

and distributed transactions. ET E 
= CockroachDB is written in the Go programming language. 9 See — f e H 
= CockroachDB has built-in Change Data Capture feature, 

that you can build the Transactional Outbox Pattern with eee 

E 


CDC into your own application. 


https://www.cockroachlabs.com/docs/stable/change-data-capture-overview.html 
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Azure Cosmos DB for CDC and Outbox Pattern 


= Azure Cosmos DB is a globally distributed, multi-model 
database service offered by Microsoft Azure. 


= |t supports various database models, including document, 
key-value, column-family, and graph, and can be 
accessed through multiple APIs, such as SQL, MongoDB, 
Cassandra, and Azure Table Storage. 


= Azure Cosmos DB has built-in support for Change Data 


Capture (CDC), allows it to track and propagate data ig == 
changes made to the database to other systems in near e LA O aaa E 


real-time. 


= CDC in Azure Cosmos DB works by continuously Ht aan 
monitoring the transaction logs of the database for 5 
changes and extracting those changes to be sent to 
target systems. 


= Azure Cosmos DB change feed API to access the data 
changes and process them in your application. 


Event-Computing and Notifications 
Retail, Gaming, Content management 


Stream Processing 
loT processing, Data Science & analytics 


mA: spare 22> Sidkw 


Azure Apache 
Stream Analytics Spark 


a 
Zei 


Apache 


Azure 
HDinsight Storm 


Data movement 
Enterprise data management 


https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed-design-patterns 


Mehmet Ozkaya 535 


Amazon DynamoDB Streams for CDC and Outbox 


= DynamoDB supports streaming of item-level change data 
capture records in the near-real time. 


= DynamoDB stream is an ordered flow of information about 
changes to items in a DynamoDB table. 


= Whenever an application creates, updates, or deletes items in _ Ee 


3. A stream record contains information about a d 


the table, DynamoDB Streams writes a stream record with the , TEL te in a DynamoDB ia 
primary key attributes of the items that were modified. 


Amazon DynamoDB Stream 


EventType = 


, , , d CJ Insert iterp E 007 Poll-based 
= A stream record contains information about a data modification „esi, a tear Lued 


to a single item in a DynamoDB table. That can includes capture prenons 
additional information, such as the “before” and “after” images of 
modified items. 


https://medium.com/aws-lambda-serverless-developer-guide-with-hands/dynamodb-streams- 
using-aws-lambda-to-process-dynamodb-streams-for-change-data-capture-2e3ab8df27ca 


= DynamoDB Streams writes stream records in near-real time so 
that you can build applications that consume these streams and 
take action based on the contents. 


= Most of the applications can benefit from data capturing changes 


into DynamoDB table; Notifications, Mobile Apps, Financial 
Apps. Mehmet Ozkaya 536 


Amazon DynamoDB Streams for CDC and Outbox 


AWS Cloud Steps 
1. modifies data in a DynamoDB table 
2. DynamoDB Streams captures a time-ordered sequ 
3. Astream record contains information about a data 
modification to a single item in a DynamoDB table. 
4. Develop Lambda function for incoming event from 
Amazon DynamoDB Stream 


EventType = 
9 Insert Iterk a Poll-based 
Ce : 
Client Lambda 
Application AWS Lambda function 


https://medium.com/aws-lambda-serverless-developer-guide-with-hands/dynamodb-streams-using-aws-lambda-to-process-dynamodb-streams-for-change-data- 
capture-2e3ab8df27ca 
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Before Design — What we have in our design toolbox ? - Data 


Architectures Patterns&Principles Microservices Data 


Microservices e 
Architecture 


The Database-per- 
Service Pattern ! 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube ` 


Microservices 
Decomposition Pattern 


Microservices 
Communications 
Patterns 


Microservices Data 
Management Patterns 


Choosing Database 


The Shared Database Anti- e 
pattern 


Relational and NoSQL 
Databases 


CAP Theorem—Consistency, 
Availability, Partition 
Tolerance 


Data Partitioning: 
Horizontal, Vertical and 
Functional Data Partitioning 


Database Sharding Pattern 


Microservices Data 
Commands&Queries 


Materialized View Pattern 


CQRS Design Pattern 


Event Sourcing Pattern 


Eventual Consistency 
Principle 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an orde 


List my old orders and 
order items history 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 
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Independent 


Architectures Patterns&Principles Microservices Data 
Choosing Database 


The Shared Database Anti- 


Before Design — What we have in our design toolbox ? - New 


Microservices e 
Architecture 


The Database-per- 
Service Pattern ! 


Polygot Persistence 


Decompose services by 
scalability ° 


The Scale Cube 


Microservices e 
Decomposition Pattern 


Microservices 
Communications S 
Patterns 


Microservices Data 
Management Patterns 


Microservices 


Distributed ° 
Transaction Pattern . 


pattern, Relational and 
NoSQL Databases 


CAP Theorem—Consistency, 


Availability, Partition 
Tolerance 


Data Partitioning: 
Horizontal, Vertical and 


Functional Data Partitioning 


Database Sharding Pattern 
Microservices Data 
Commands&Queries 


Materialized View Pattern 


CQRS Design Pattern 
Event Sourcing Pattern 


Eventual Consistency 


Microservices 
Distributed 
Transactions 
SAGA Pattern 


Choreography and 
Orchestration-based 
SAGA 


Compensating 
Transaction Pattern 


Dual-Write Problem 


Transactional Outbox 
Pattern 


CDC - Change Data 
Capture 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an orde 


List my old orders and 
order items history 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 
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Independent 


Microservices with SAGA, Transactional Outbox 
and CDC Pattern 


re |] 22-2222 
i Client Apps! 


A 
f 


> m 
K ` 5 
Lem a 
a | St event o 
I! m 
p! SAGA a 
D S : Pattern 
E < + Ordering 
| E Log-based| ct 
CDC | publish 
ain Debezium| event 


New Data 
Changed 
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Adapt: Microservice Architecture with SAGA, 


Transactional Outbox and CDC Pattern 


Frontend SPAs Client Apps! | Microservices with SAGA, Outbox and CDC Pattern 
I I 
e Vue i ' i 
. React O il Shopping 
API Gateways ' ry E “i Eat m | 
a ) T H D i] 
i g i 
. Kong Gateway ! wep HH! e d Discount_ = | 
, Express Gateway ! fb g saca | & |! 
e Amazon AWS API Gateway LC 1” | 2 | ordering = 1 
Message Brokers Event Bus ; fn Wi —_— ai 1 
e Kafka Mobi i Transa fio, D event 
, RabbitMQ 7 Ke < ! 
, Amazon EventBridge, SNS E Table | Table j changed | 
Backend Microservices Kee aere =otatd.----------4 
, Java — Spring Boot Log-based built-in CDC Database CDC — Open Source Tool 
Net — Asp.net e CockroachDB eben 
JS 8 NodeJS , Azure CosmosDB 


, Amazon DynamoDB Streams Mehmet Ozkaya 541 


Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservice Architecture with SAGA, 
Transactional Outbox and CDC Pattern 


Benefits 

Maintain the integrity of your database 
transactions 

Real-time synchronization 

Extracting and propagating changes to be kept 
up-to-date with the data 

Decouple data and propagate events 

Easier to scale and maintain a microservices 


=< Chererer e E ERC 
Client Apps! 


Aema}ed IdV 


sng Ian? 


| Ordering | 


ame _S 
Transa fion) Ce 
et as 
| Table | Table New Data 


Drawbacks 

« Increased Complexity, Outbox Pattern and CDC 
makes your system more complex design. 

, Add latency to the event publishing process 

e Performance burden on the database 

e Difficult to set up and maintain 


fe em ep ep e ees Se Se Se Se e SS SS e e we ee Ss eB wn ew em em om ewe em 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Handle Millions of Events 


Across Microservices 


Considerations 

e What if we have thousands of microservices that need to 
communicates with millions of events ? 

e If multiple subsystems must process the same events 

e Required Real-time processing with minimum latency. 

e Required complex event processing, like pattern matching 


“ses ece EE ee ee ee ee 
Client Apps , 


e Required process high volume and high velocity of data, E m 
f eg 1) 
i.e. lol apps. 9 Ee = 

2 SAGA = 

Problems 5 rai i 

e Decoupled communications for thousands of SC 

, ! ame ` publis 
microservices Gal ee event 


Order 
GD | Table 


e Real-time processing 
e Handle High volume events 


fe em ep ep we ees se se zs SS zz e e ete wp es es we em em em ew ewe wm 
em mm emm em em wm wm em em em em em wm wm mm em mm M 


Solutions 


e Event-driven architecture for microservices 
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Event-Driven 
Microservices Architecture 


Asynchronous communication, Decoupled communication 
Event Hubs 

Stream-Processing 

Real-time processing 

High volume events 
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Problem: Handle Millions of Events 


Across Microservices 


Considerations 

e What if we have thousands of microservices that need to 
communicates with millions of events ? 

e If multiple subsystems must process the same events 

e Required Real-time processing with minimum latency. 

e Required complex event processing, like pattern matching 


“ses ece EE ee ee ee ee 
Client Apps , 


e Required process high volume and high velocity of data, E m 
f eg 1) 
i.e. lol apps. 9 Ee = 

2 SAGA = 

Problems 5 rai i 

e Decoupled communications for thousands of SC 

, ! ame ` publis 
microservices Gal ee event 


Order 
GD | Table 


e Real-time processing 
e Handle High volume events 
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Solutions 


e Event-driven architecture for microservices 
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Introduction - Event-driven Architecture 


= WMicroservices architectures are designed to be highly 
modular and flexible, that can be scaled and managed 
separately and use of APIs to communicate between services. 


= Event-driven architecture, microservices can communicate EE LL LETS 


by publishing and subscribing to events, than directly calling 


each other's APIs. 


= Event-driven microservice architecture is means 
communicating with microservices via event messages and 


we can do asynchronous behavior and loosely coupled. Ly 3 tt S 
Order l ANALNE 


= Instead of sending request when data needed, services 
consume them via events. 


= Huge innovations on the Event-Driven Microservices 
Architectures; 


= Real-time messaging platforms, stream-processing, event 
hubs, real-time processing, batch processing, data 


intelligence. 
Mehmet Ozkaya 548 


Event-Driven Microservices Architecture 


= Event-driven microservices architecture, services 
communicate with each other by publishing and subscribing 
to events. 


= When a service needs to communicate with another service, it 


publishes an event to a message queue or event bus. Other E Event-driven Microservices Architecture 
services can then subscribe to that event and take 


appropriate action when the event is received. 


Create 
= Asynchronous communication 
Allows services to communicate asynchronously. Service can o 
publish an event and continue processing without waiting for a Ce 
response from the other service. 


= Decoupled communication 
Decouples the publisher and subscriber, allows to evolve 
independently without affecting each other. 
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Event-Driven Microservices Architecture - 2 


= Real-time processing 
Support real-time processing, as events are published and 
consumed as soon as they occur. Need to react to events in 
real-time, such as in systems that use CDC to track changes to 
a database. 


Event-driven Microservices Architecture 


Create Validate ` / 

Order / _ Payment x 

aN | 
Order Event Bus Y 


= High volume events 
Well-suited to handling high volume events, as they can scale 
horizontally by adding more event consumers as needed. Can 
be scaled independently to handle increased load. 


= Responsible business capability 
Each service is responsible for a specific function or business 
capability. 


= Services communicate with each other by publishing and 
subscribing to events, that make it easier to build and maintain 
complex systems. 


= Allows to work on different parts of the system in parallel 
without having to worry about the impact on other components. Mehmet Ozkaya 550 


Real-time Processing and High Volume Events 
in Event-Driven Microservices Architecture 


Real-time processing 
Real-time processing is achieved by using a message queue or event bus to publish and consume events 
as they occur. 


When an event is generated, it is published to the message queue or event bus and made available to any 
interested subscribers. 


Allows you to react to events in real-time, as they are published and consumed as soon as they occur. 
When need to perform real-time analytics or trigger actions based on changes to the data. 


High Volume Events 
Using a message queue or event bus that can handle high volumes of events and distribute them to 
multiple consumers. 


When you have a system that generates a large number of events, use a event bus to distribute those 
events to multiple consumers, that can process events in parallel. 


Allows you to scale up the number of event consumers as needed to handle increased load. 


Event-driven microservices architectures to process events in real-time and scale to handle high volumes 


of events. 
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Event Hubs and Event Streaming Se Hz 
in Event-Driven Microservices Architecture | rd 
= Event Hubs 


Act as a central hub for data ingestion and distribution, allowing microservices to publish and subscribe to 
data streams. 


Each microservice publish its data to an Event Hub. Other microservices can then subscribe to the Event 
Hub and consume the data as needed. 


Communicate with each other in real-time, that needs to be highly reliable and scalable. 


Event Streaming 
Allows you to capture and process a stream of events in real-time. Publish and consume events as they 
Occur. 


Allowing to build real-time data pipelines that can process and analyze data as it is being generated. 


One common use case for Event Hubs and event streaming in microservices architectures is real-time 
analytics. 
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Use Cases of Event Hubs and Event Streaming 


= Use Case — Customer Purchase on E-Commerce 
E-commerce website that generates a large number of events as customers browse and purchase 
products. 


= Using event streaming, build a real-time analytics pipeline that processes these events as they occur and 
generates insights in real-time. 


= This could include tracking customer behavior, identifying trends and patterns, and triggering actions based 
on changes to the data. 


= Use Case — Data Synchronization 
Different services may need to access the same data, and not be able to access each other's databases 
directly. 


= Using event streaming, we can build a data synchronization pipeline that captures changes made to the 
data and streams them to other services in real-time. Ensures to access the most up-to-date data. 


= Event Hubs and event streaming is a powerful tool for building real-time data pipelines in microservices 
architectures that provides flexible platform for data ingestion and distribution. 
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Real-world Examples of Event-Driven Microservices 


= E-commerce application we have a few microservices like: 
customer, order, payment and products. 


= Customer create orders with some products and, if the 
payment is successful, the products should be delivered to the 
customer. 


Event-driven Microservices Architecture 


Events 
= a customer creates an order 
= the customer receives a payment request 


Create 
Order J 


Ki 


= if the payment is successful the stock is updated and the order is delivered 


= if the payment in not successful, rollback the order and set order status is 


Complete 
not completed. 


= This is more humanly readable and, if a new business = 
requirement appears, it is easier to change the flow. 


= WMicroservices will only care about the events, not about the 
other microservices, process only events and publish new 
event to trigger other services. 


Mehmet Ozkaya 554 


Traditional Event-Driven Microservices Architecture 
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Evolved Event-Driven Microservices Architecture 


= Huge Innovations on the Event-Driven Microservices Architectures. 


= Real-time messaging platforms, stream-processing, event hubs, real-time processing, batch 
processing, data intelligence. 


= Event-Hubs is huge event store database that can make real-time processing. 


Web Custom Apps Microservices Monitoring Analytics 


= Hil 
i 
egenen 
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Kafka Event-Driven Microservices Architecture ie 


e Global-scale 
e Real-time 


e Persistent Storage 
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Architectures Patterns&Principles Microservices Data 
Choosing Database 


The Shared Database Anti- 


Before Design — What we have in our design toolbox ? - Old 
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CQRS Design Pattern 
Event Sourcing Pattern 
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Event-Driven Microservices Architecture 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Event-Driven Microservices Architecture 


Benefits 

« Event Streaming 
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Way of Learning — The Course Flow 
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Problem: Database operations are expensive, EE -H ES 


low performance 


Considerations 

e Event-driven architecture comes with latency when 
publishing and subscribing events from the Event Hub. 

e Sync REST APIs communication make expensive calls to ryzza 
a database that reduce performance. 

e How can we make more faster that increase performance 
of communications in Microservices Architecture ? 
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Process 


Problems 

« Slowliness and Low Performance Communication 

e Latency when publishing and subscribing events 

e Rest APIs make Database calls that are expensive, low} 
performance 


Solutions 
e Distributed cache 
e Storing frequently accessed data in a distributed cache Mehmet Ozkaya 565 


Microservices Distributed 
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Microservices Distributed Caching Patterns and Practices 
Cache-Aside Pattern 

Caching strategies 

Cache invalidation 

Cache consistency 
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What is Caching ? 


= Caching for improving the performance of a system by storing 
frequently accessed data in a cache that can be quickly accessed 
from memory. 


= Caching is to reduce the number of expensive operations, such as r 
database queries or network requests. 


= Caching can increase performance, scalability, and availability for 
microservices with reducing latency with cache and makes application 
faster. 


= When the number of requests are increased, caching provide to 
handle requests with high availability. 


=" If application request mostly comes for reading data that is not 
changes so frequently, then Caching will be so efficient. 


= |.e. reading product catalog from e-commerce application. Caching 
also provide to avoid re-calculation processes. 


= By storing frequently accessed data in a cache, system can avoid the 
overhead of repeatedly expensive operations. 
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Types of Caching 


=» In-memory cache 
Stores data in the main memory of a computer. In-memory caches are 
typically the fastest type of cache, but the data is lost when the cache is 
restarted or the machine is shut down. 


= Disk cache 
Stores data on a hard drive or solid-state drive. Disk caches are slower 
than in-memory caches, but they can persist data. 


= Distributed cache 
Cache is distributed across multiple machines and is typically used in 
distributed systems, such as microservices architectures. 


= Distributed caches can improve the performance and scalability of a 
system by allowing data to be stored and accessed from multiple 
locations. 
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Distributed Caching in Microservices 


= Distributed caching is improving the performance by storing frequently accessed data in a cache that 
can be quickly accessed from multiple locations. 


= Microservices architectures are typically implement a distributed caching architecture: 
= Improve the performance of individual services by storing frequently accessed data locally. 
= Reducing the need to make expensive calls to a database or other external system. 


= How can we increase the speed of the microservices ? With using Distributed Cache. 


Microservices Distributed Caching 
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Distributed Caching in Microservices - 2 


= WMicroservices are responsible for a specific function and 
communicates with other services through well-defined 
interfaces, typically using APIs. 


= By storing frequently accessed data locally in a cache, 
microservices can avoid the overhead of making repeated 
calls to an external system, resulting in faster response times. 


= Benefits to using distributed caching in a microservices: 


= Improved performance 
Services can avoid the overhead of making repeated calls to a 
database or other external system. 


= Resilience 
Allowing services to continue functioning even if an external 
system becomes unavailable. 


= Scalability 
Allowing services to handle increased traffic without the need to 
scale up the external system. 
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Cache Hit and Cache Miss 


= Cache hit occurs when the requested data can be found in 
the cache. 


= Cache miss occurs when the requested data is not in the 
cache and must be retrieved from a slower storage db. 


= Cache hits are desirable because they can improve the 
performance of a system by reducing the number of 
requests. 


Microservice 


= Cache misses can have a negative impact on performance, 
because they require additional time and resources to retrieve 
the requested data. 


= The cache hit rate is a measure of how often a cache is able 
to fulfill requests from its own store. 


= High cache hit rate indicates that the cache is effective at 
storing frequently accessed data. 


= Low cache hit rate may indicate that the cache is not large 


enough. Mehmet Ozkaya 572 


Caching Strategies in Distributed Caching 


There are several caching strategies that can be used in 
distributed microservices: 

= Cache Aside 

= Read-Through 

= Write-Through 

= Write-Back, Write-Behind 


Cache Aside Strategy 

Client checking the cache for data before making a request to 
the backend service. When microservices needs to read data 
from the database, it checks the cache first to determine 
whether the data is available. 


Microservice 


If the data is available (a cache hit), the cached data is 
returned. If the data isn’t available (a cache miss), the 
database is queried for the data. 


The client will retrieve the data from the backend service and 
store it in the cache for future requests. 


Data is lazy loaded into cache by client application. Mehmet Ozkaya 573 


Caching Strategies in Distributed Caching 


= Read-Through Strategy 
When there is a cache miss, it loads missing data from the 
database, populates the cache and returns it to the application. 


= When a client requests data that is not found in the cache, 
the cache will automatically retrieve the data from the 
underlying database and store it in the cache for future 
requests. 


= Cache-aside strategy, when a client requests data that is not Microservice 
found in the cache, the client is responsible for retrieving the 
data from the database. 


= Read-through cache strategy, when a client requests data 
that is not found in the cache, the cache will automatically 
retrieve the data from the database. 


= Cache always stays consistent with the database. 
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Caching Strategies in Distributed Caching 


= Write-Through Strategy 
Update the cache whenever data is written to the backend 
service. Cache always has the most up-to-date data, but it can 
also result in a higher number of write operations. 


= Instead of lazy-loading the data in the cache after a cache 
miss, the cache is proactively updated immediately following Cache 
the primary database update. 


= Data is first written to the cache and then to the database. Microservice 


= Write-Back or Write-Behind Strategy 
Delays updating the cache until a later time. This reduce the 
number of write operations, but the cache may not have the 
most up-to-date data. 


= In Write-Through, the data written to the cache is 
synchronously updated in the main database. 


=" in Write-Back or Write-Behind, the data written to the cache is 
asynchronously updated in the main database. 
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Cache-Aside Pattern for Microservices 


= (1) When a client needs to access data, it first checks to see if the 
data is in the cache. 


= (2) If the data is in the cache, the client retrieves it from the cache and 
returns it to the caller. 


= (3) If the data is not in the cache, the client retrieves it from the 
database, stores it in the cache, and then returns it to the caller. 


= Some of caching systems provide read-through and write- 
through/write-behind operations. In these systems, client 
application retrieves data over by the cache. 


= For not supported Caches, it's the responsibility the applications 
use the cache and update the cache if there is a cache-miss. 


= WMicroservices good example to implement Cache-Aside pattern, it 
is common to use a distributed cache that is shared across 
multiple services. 
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Cache-Aside Pattern for Microservices - 2 


= Cache-aside pattern can improve performance of a microservices 
architecture, by reducing the number of expensive database calls. 


= To use the Cache-aside pattern in a microservice, need to 
implement a cache layer in your service. 


= Involve using a Cache library or framework, such as Redis or 
Memcached, or implementing a custom cache solution. 


Process: 


is in the cache. 


= If the data is in the cache, the service retrieves it from the cache and 
returns it to the caller. 


= Ifthe data is not in the cache, the service retrieves it from the 
database or other data store, stores it in the cache, and then returns it 
to the caller. 
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Drawbacks of Cache-Aside Pattern for Microservices 


= Cache can introduce additional complexity and may not be suitable 
for all situations. 


= The cache may need to be invalidated or refreshed when data is 
updated in the database or data store. 


= This can require additional coordination between the 
microservices. 


= The cache may introduce additional latency if it is located remotely 
from the microservices that are using it. 
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Microservices Distributed Caching 
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Microservices Distributed Caching 
apply Cache-Aside Pattern on API Gateway 


1. User makes a request to an API gateway to retrieve some data. 


2. API gateway determines which microservice is responsible for handling the request and receives the request 
and checks to see if the data is in the cache. 


3. If the data is in the cache, API gateway retrieves it from the cache and returns it to the client. 


4. Ifthe data is not in the cache, API gateway forward responsible microservice to retrieves it from the database, 
and then returns it to the API gateway. 


5. The API gateway receives the data from the microservice and stores it in the cache and returns it to the user. 
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Cloud Distributed Caches 


ə Amazon ElastiCache 


e Azure Cache for Redis 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservices Distributed Caching 


Benefits 

Improved performance; by storing frequently 
accessed data in a cache 

Enhanced scalability; by offloading some of the 
workload from the database 

Increased reliability; cache can continue to 
serve data even if one of the nodes fails. 


Distribute Microservices 
Cache 


Client Apps 


Drawbacks 

- Increased Complexity; cache can be complex 
and require specialized knowledge. 

e Cache invalidation; Maintaining the consistency 
of the cache can be challenging, can lead to eege ee eege 
issues. 

, Cost; managed services from cloud providers, 
can be expensive 

- Cache stampede Mehmet Ozkaya 585 
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Problem: Deploy Microservices at Anytime 
with Zero-downtime and flexible scale 


Problems 

e Business teams wants to add new features immediately 

e Innovate and experiment with new features 

e Deploy features immediately, not waiting for deployment dates. 


eee zm em zm 1 


e Flexible scale for market peek times Client Apps 


Considerations 

e Ensure continuity of service and minimize disruption 
e Allow for continuous delivery 

e Support high-traffic environments 


Solutions 

« Containers and Orchestrators 

e Deployment strategies; blue-green deployment, rolling 
deployment, and canary deployment. l-------- 

e Kubernetes Patterns; Sidecar Patterns, Service Mesh Pattern 

e DevOps and CI/CD Pipelines and Infrastructure as code (a 
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Microservices Deployments 
with Containers and 
Orchestrators 


Deployment strategies; blue-green, rolling and canary deployment. 
Kubernetes Patterns; Sidecar Patterns, Service Mesh Pattern 
DevOps and CI/CD Pipelines 

Infrastructure as code (laC) 
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What are Containers ? 


= Monolithic applications are deployed as a single unit and deploy whole 
application in one time. 


= This caused temporarily un-available time of application, needs to rollback 
the whole deployment process. Can't split modules and scale independently. 


= \|t solved in microservices architecture with Containers and Orchestrators. 


= Containers are package and distribute software applications, makes them Il S 


easy to deploy and run on different environments. 


= Allow developers to package an application and its dependencies into a 
single, self-contained unit container images, easily shipped and run on any 
computer that has a container runtime. 


= Containers are often used in the deployment of microservices, independent 
components can be developed, tested, and deployed separately. 


= Each microservice is typically a self-contained unit, communicates with other 
microservices through well-defined interfaces. 
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What are Containers ? - 2 


= Containers provide to decouple applications with their own os, 
dependencies and libraries, perfect match to microservices deployments. 


= Microservices can deployed separately in a container. Each microservice can 
deploy independently with containers. 


= Since deployed microservices separate container, we can scale as per their 


volume of traffics. Ii 
= Changes can be applied independently while other container stay not il S 


changed. 


= New features can be applied and rollback very easy with container 
deployments. 


= Docker is defacto standard for containerization of microservices. 
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Advantages of Containers 


= Isolation 
Each microservice runs in its own container, provides isolation from the other 
microservices and the host operating system. 


= Scalability 
Containers make it easy to scale microservices horizontally by simply running 
more instances of a containerized microservice. 


= Portability 
Containers allow microservices to be easily deployed and run on any computer 


or cloud platform that supports container runtime. 


= Resiliency 
Microservices are intended to be independently deployable and scalable. Using 
containers in the deployment of microservices that can be quickly started and 
stopped, increase the resiliency of the application. 
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What is Docker ? 


= Docker is an open platform for developing, shipping, and running 
applications. 


= Separate your applications from your infrastructure so you can deliver 
software quickly. 


= Advantages of Docker’s methodologies for shipping, testing, and deploying 
code quickly. 


= Significantly reduce the delay between writing code and running it in 
production. 


= Automating the deployment of applications as portable, self-sufficient docker 
containers that can run on the cloud or on-premises. 


= Docker containers can run anywhere, in your local computer to the cloud. 


= Docker image containers can run natively on Linux and Windows. 


= Docker is defacto standard for containerization of microservices. 
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Docker Containers, Images, and Registries 


= Developer develops and packages application with its dependencies 
into a container image, that is a static representation of the 
application with its configuration and dependencies. 


= To run the application, the application’s image is instantiated to create 
a container, which will be running on the Docker host. 


= Store images in a registry, which is a library of images and is needed 
when deploying to production orchestrators. 


= Docker images are stores a public registry like Docker Hub, Azure 
Container Registry. 


= Developer creates container in local and push the images the 
Docker Registry. 


= Developer download existing image from registry and create 
container from image in local environment. 


Mehmet Ozkaya 595 


Application Containerization with Docker 


1. Write Dockerfile for our application. 
2. Build application with this docker file and creates the docker images. 


3. Run this images on any machine and creates running docker container 
from docker image. 


Dockerfile Docker Image Docker Container 


= Orchestrating whole microservices application with Docker and Kubernetes. 
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Why need Orchestrator for Containers ? 


= Why we need to orchestrate our containers ? 


= Think to developed and containerize our microservices and ready for shipping 
and deployment. Why we need an orchestrator for our containers ? 


= Deployment requirements of microservices, think that have hundreds of 
microservices, we should ask; 


kubernetes 


How container instances be provisioned into cluster of multiple machines ? 

After deployment, how will containers discover and communicate with each other ? 
How can containers scale in or out on-demand and peek traffic ? 

How do you monitor the health of each container ? ep 
How do you protect containers against hardware and software failures ? docker 
How do upgrade containers for a live application with zero downtime ? 


= All these questions handled by Container Orchestrators that automate all 
these concerns. 


= These task can not be managed by manually administrated for thousands of 
independently deployed containers. 


= Containerized services require automated management. 
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What is Container Orchestrator ? 


= Container orchestrators are manage and automate the deployment, 
scaling, and management of containerized applications. 


= Enable to run and manage microservices-based applications in an efficient 
and scalable way by abstracting the underlying infrastructure and handling 
tasks such as resource allocation, load balancing, and monitoring. 


= Microservices architectures, containers need to orchestrate to manage lots of 
container in your application cluster. 


= Orchestrators automates the deployment, scaling, and operational 
concerns of containerized workloads across clusters. 


= Container orchestrator automates the deployment and management of these 
microservices, making it easier to scale and update application as needed. 


= There are several popular container orchestrators available, including 
Kubernetes, Docker Swarm, and Apache Mesos. 


docker 
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Application Containerization and Orchestration 


1. Package each of microservices into a container image and push it to a container registry. 
2. Then use the container orchestrator to deploy the microservices to a cluster of nodes. 


3. Orchestrator will handle tasks such as scheduling containers onto nodes, monitoring the 
health of the containers, and providing self-healing capabilities if a container fails. 


kubernetes 


docker 
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Benefits of Using Container Orchestration 


Automation 
orchestrator can automate the deployment and management of your 
microservices. 


Scalability 
orchestrator can automatically scale your microservices up or down as needed > 
meet changing demand. 


Lal 
High availability 

orchestrator can provide self-healing capabilities to ensure that your 
microservices remain available even if individual containers fail. 


Improved resource utilization 
Orchestrator can optimize the use of resources in your cluster. 


Portability 
Containerized applications can be easily moved between different environments docker 
and platforms. 


Security 
orchestrators provide security features such as role-based access control and 
network segmentation. Mehmet Ozkaya 600 


What is Kubernetes ? 


= Kubernetes (also known as k8s or "kube") is an open source container 
orchestration platform. 


= Automates many of the manual processes involved in deploying, managing, 
and scaling containerized applications. 


= Developed by Google and is now maintained by the Cloud Native Computing 
Foundation (CNCF). 


= Kubernetes is a portable, extensible, open-source platform for managing 
containerized workloads and services, both declarative configuration and 
automation. 


docker 


= It has a large, rapidly growing ecosystem. Kubernetes services, support, and 
tools are widely available. 


= Create cluster groups of hosts running Linux containers, Kubernetes helps 
you easily and efficiently manage those clusters. 


= Kubernetes is designed to provide a platform-agnostic way to manage 
containerized applications at scale. 
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Benefits of Kubernetes 


Self-healing 
Kubernetes can automatically restart containers that fail, ensuring that your 
microservices remain available even if individual containers go down. 


Automatic scaling 
Automatically scale your microservices up or down as needed to meet changing 
demand, making it easier to handle sudden spikes in traffic. 


kubernetes 


Load balancing 
Automatically distribute incoming traffic across multiple instances of a 
microservice. 


Declarative configuration 
Allows to specify the desired state of your microservices using configuration files; 
easy to automate the deployment and management of your applications. 


docker 
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Kubernetes Architecture 


Kubernetes Master 


>> APIServer F 


Node Node Node Node 
| Kube-proxy ` = __Kube-proxy ` 


https://kubernetes.io/docs/concepts/overview/components/ 


Mehmet Ozkaya 603 


Kubernetes Components 


= Pods 
Pods are the smallest deployable units of computing, that you can create and 
manage in Kubernetes. Pods stores and manage our docker containers. 


= ReplicaSet 
Maintain a stable set of replica Pods running at any given time. Used to 
guarantee the availability of a specified number of identical Pods. 


= Deployments 
Provides declarative updates for Pods and ReplicaSets. Describe a desired 
state in a Deployment, and the Deployment Controller changes the actual state 
to the desired state at a controlled rate. 


= Deployments are an abstraction of ReplicaSets, and ReplicaSets are an 


abstaction of Pods. 8 
= Pods should not created directly, if needed, Deployment objects should be @ @ a 
created. 
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Kubernetes Components - 2 


= Service 
Expose an application running on a set of Pods as a network service. 
Kubernetes gives Pods their own IP addresses and a single DNS name for a 
set of Pods, and can load-balance across them. 


= ConfigMaps 
API object used to store non-confidential data in key-value pairs. Pods can 
consume ConfigMaps as environment variables, command-line arguments, or 
as configuration files in a volume. 


= Secrets 
Store and manage sensitive information, such as passwords, OAuth tokens, 
and ssh keys. 


= Volumes 
Persistent storage location that can be mounted into a pod. Volumes can be 
used to store data that needs to persist across container restarts or be shared 
between multiple containers in a pod. 
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Helm Charts with Kubernetes feste 
for Microservices Deployments | rd 


= Helm is a package manager for Kubernetes that makes it easier to manage 
and deploy applications in a Kubernetes cluster. 


= Helm uses a packaging format called charts, which are collections of files 
that describe the various components of an application (Such as pods, services, 
and deployments) 


= It allows you to automate the deployment of complex applications in a Hy 
Kubernetes cluster. HELM 
= Instead of manually creating and managing each component of your mA 


application separately, can use a single Helm chart to define all of the 
components and their relationships. 


= This makes it much easier to manage and update your application over time. 
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Benefits of Helm Charts with Kubernetes 
for Microservices Deployments 


= Reusability 
Helm charts can be shared and reused across multiple clusters, making it easy 
to deploy the same application in different environments. 


= Version control 
Allowing to track changes to your application over time and roll back to previous 
versions if needed. i , 


= Customization HELM 
Allow you to override the default settings for a chart and tailor it to your specific A 
needs. 


Ei ER 
(ë) 
Ea 


Staging 
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Sidecar Pattern 


= Sidecar pattern is a design pattern in which a helper container is run 
alongside the main container in a pod. 


= The Sidecar container performs cross-cutting tasks that are related to 
the main container. 


= Common use case for the sidecar pattern is to add logging or 
monitoring functionality to a container. 


= A sidecar container that runs a logging agent that sends application 
logs to a central logging server, and also provide to monitoring the 
health of the main container. 


= These cross-cutting tasks can be implemented as separate services 
with sidecar pattern such as monitoring, logging, configuration, and 
networking services. 


= The sidecar container and the main container share the same network 
namespace, that allows the sidecar container to access and manipulate 
the data produced by the main container as needed. 


Primary Application 


Core functionality 


Sidecar 


Peripheral tasks such as: 


+ Platform abstraction 

e Proxy to remote services 
e Logging 

* Configuration 
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Benefits of Sidecar Pattern 


= Allows to add functionality to a container without modifying the 
container itself. 


= Useful if you want to add logging or monitoring functionality to an 
existing container image that you do not control. 


= Allows you to decouple the main container from the sidecar 
functionality, easier to update or replace the sidecar without affecting 
the main container. 


= Allows to run multiple containers in a pod that share the same network . 


namespace, making it easier to communicate between them. 


= Allows to add common functionality to multiple microservices without 
having to modify the microservices themselves. 


Sidecar 


e Se? Peripheral tasks such as: 
Primary Application d 

e Platform abstraction 

e Proxy to remote services 
e Logging 

* Configuration 


Core functionality 
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Drawbacks of Sidecar Pattern 


= Increased complexity 
Adding an additional layer of complexity to your deployment, more difficult 
to understand and troubleshoot issues that arise. 


= Increased resource usage 
Running an additional container in a pod will increase the resource usage : 


of the pod. Sidecar 
a Decreased performance e Primary Application Peripheral tasks a as: 
Pod can potentially decrease the performance of the pod, as the sidecar : | core unctionaity ens ae 


container will be competing for resources with the main container. : es a 


= Limited flexibility 
Can be inflexible in some cases, as it requires that the main container 
and the sidecar container run in the same pod. 
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When to use Sidecar Pattern 


= When you want to add functionality to an existing container image 


= When you want to decouple the main container from the additional 
functionality 


= When you want to run multiple containers in a pod that need to 
communicate with each other 


= When you want to add common functionality to multiple microservices 


Sidecar 


e Se? Peripheral tasks such as: 
Primary Application d 

e Platform abstraction 

e Proxy to remote services 
e Logging 

* Configuration 


Core functionality 
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Service Mesh Pattern 


= Service mesh pattern is managing the communication between 
microservices in a distributed system. 


= Designed to provide a uniform way to route traffic between 
microservices, handle load balancing, and monitor the healths. 


= Consists of a set of proxy servers (sidecars) that are deployed 
alongside the microservices. Proxy servers handle the communication 
between the microservices. 


= Responsible for tasks such as routing requests, load balancing, and 
monitoring the health of the system. 


= Abstract away the complexities of managing communication 
between microservices. 


= Instead of having to manage these details at the application level, use 
the service mesh to handle them automatically. 


= Popular Service mesh implementations, including Istio and Linkerd, set 
up and manage a service mesh in a Kubernetes cluster. 
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When to use Service Mesh Pattern 


= When you want to abstract away the complexities of managing 
communication between microservices. 


= When you want to centralize the management of communication 
between microservices. 


= When you want to add features such as load balancing, traffic 
management, and monitoring to your microservices. 


= Using a service mesh, can add these features to your microservices 
without having to modify the microservices themselves. 


= Service mesh pattern is a useful tool for managing the communicatior 
between microservices in a distributed system. 


= Build and maintain complex microservices-based systems by 
abstracting away the complexities of managing communication between 
the microservices. 
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Devops and CI/CD Pipelines 


= DevOps is to improve the efficiency and speed of software development 
and deployment by automating and streamlining the processes involved. 


= Continuous Integration / Continuous Delivery (CI/CD) pipeline. 


= CI/CD pipeline is a series of automated processes that are used to build, 
test, and deploy software. 


Continuous Integration 


A AE: 5 


Build tasks Test tasks Create artifact 


= For microservices deployments, a CI/CD pipeline can be used to 
automate the process of building, testing, and deploying microservices. 


Continuous Deployment 
= CI/CD pipeline to automatically build and test new versions of a Lë é Rt el 
microservice, and then deploy the new version to a staging or production 
environment. 


Edit Code Push to code repo 


Deploy to target 


= CI/CD pipeline is to enable teams to quickly and reliably deliver changes 
to microservices with zero-downtime. 


= Deploy updates to individual microservices as needed rather than having 
to deploy updates to the entire system at once. 


= Automate and streamline the process of building, testing, and deploying 
microservices. Mehmet Ozkaya 614 


CI/CD Pipeline Steps for Microservices Deployments = tT 


Hs» 
AA 


Edit Code Push to code repo 


Dër € 


Deploy to target 


Continuous Integration 


Build tasks Test tasks 


= Continuous Deployment | 


Release tasks 


> SC 


Create artifact 


Mehmet Ozkaya 615 


CI/CD Tools for Microservices Deployments 


A Microsoft l , 
Azure Container Service - 


Kubernetes 


2 ey 
Application 
code repo = Build, Cl 

(SCC) 


© "ke 


docker push 


— 
Code iim | 


Custom 


image 
git push 
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Deployment Strategies for Microservices 


= Blue-green deployment 
Deploying updates to a new set of microservices (the "green" deployment), while the old version of the 
microservices (the "blue" deployment) remains running. 


= Rolling deployment 
Deploying updates to a subset of the microservices at a time, and then rolling the updates out to the rest 
of the microservices over time. 


= Canary deployment 
Deploying updates to a small subset of the microservices, and then gradually rolling the updates out to 
the rest of the microservices over time. 


= A/B testing 
Deploying updates to a subset of the microservices, and then comparing the performance of the updated 
microservices with the performance of the unmodified microservices. 
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Infrastructure as Code (laC) 


= Infrastructure as a codebase that can be managed and versioned in the same way as application 
code. 


= laC is to enable teams to manage their infrastructure in a more automated and repeatable way. 


= laC can be used to automate the process of deploying and managing the infrastructure needed to 
run the microservices. 


= Le define the infrastructure needed to run your microservices in a Kubernetes cluster, including the 
pods, services, and other resources required. 


= Terraform is a tool that allows you to define and manage infrastructure as code. 
= Ansible is a tool that allows you to automate the deployment and management of infrastructure. 


= They can be used to define the infrastructure needed to run your microservices in a Kubernetes 
cluster. 


= laC is a useful tool for automating the process of deploying and managing the infrastructure. 


= Teams can manage their infrastructure in a more repeatable and automated way, making it easier to 
update and maintain their microservices over time. 
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Before Design — What we have in our design toolbox ? - Old 


Architectures Patterns&Principles Microservices Caching 


Microservices ° 


Architecture 


Event-Driven 
Microservices 
Architecture 


The Database-per- 
Service Pattern 


Polygot Persistence 


Decompose services by 
scalability 


The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications Patterns 


Microservices Data 
Management Patterns 


Event-Driven Architecture 


Microservices 
Distributed Caching 


Caching Strategies 
Cache Invalidation 
Cache Hit - Cache Miss 


Cache-Aside Pattern 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Before Design — What we have in our design toolbox ? - New 


Architectures Patterns&Principles 


Microservices — 
Architecture 


Event-Driven 
Microservices 
Architecture 


The Database-per- 
Service Pattern, Polygot 
Persistence, Decompose 
services by scalability, 
The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications Patterns 


Microservices Data 
Management Patterns 


Event-Driven Architecture 


Microservices Distributed 
Caching 


Microservices 
Deployments with 
Containers and 
Orchestrators 


Microservices 
Deployment 


Docker and Kubernetes , 


Architecture, Helm Charts 


Kubernetes Patterns; 


Sidecar Patterns, Service 


Mesh Pattern 


DevOps and Cl/CD 
Pipelines 


Deployment Strategies; ° 


Blue-green, Rolling, 
Canary and A/B 
Deployment. 


Infrastructure as code 
(laC) 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Microservices with Containers and Orchestrators 
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CI/CD Pipeline Steps for Microservices Deployments = tT 


Hs» 
AA 


Edit Code Push to code repo 


Dër € 


Deploy to target 


Continuous Integration 


Build tasks Test tasks 


= Continuous Deployment | 


Release tasks 


> SC 


Create artifact 
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Frontend SPAs Client Apps ! 
e Angular 
e Vue $ » 
- React l 


fen 


I 
\ l 
Q i 


API Gateways 

e Kong Gateway 

e Express Gateway 

, Amazon AWS API Gateway 


Backend Microservices 


ii Catalog 
La 


docker docker Ze Zi ! 


Microservices with Containers and Orchestrators 


got Lé Grieg ) 


A OOO oOo Oo UU 
a. ae 


& 


$ .Net — Asp.net er b Y = "Stream HELM les mY 
e JS — NodeJS Jh rafom | Process | E kubernetes ww 
Container Tools Orchestrator Tools Cloud Orchestrator Service Mesh laC Cloud laC 
e Docker e Kubernetes e AKS, EKS, GKS e Istio e Terraform . AWS 
e Containerd e Helm Charts e AWS Elastic Beanstalk . Linkerd e Ansible CDK 


, Podman e Azure Container Apps Mehmet Ozkaya 623 


CI/CD Tools for Microservices Deployments 


Container Service — 
Kubernetes 


E 


2. 
Application Build. Cl 


code repo 


7 


(SCC) 


© "ke 


SCC 
D Github T docker N 
° Gitlab Code nie - 


laC 
, AWS Push | a , Terraform 
CodeBuild pemn : sec 
tee Registry Deployment Monitor ° 
oa. DockerHub ° EE Charts e Prometheus 
(eae ` ACR e Ansible Scripts e Datadog 
e GCR e Azure Devops e Amazon CloudWatch 
e AWS e Azure Monitor 
CodeBuild 
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How many concurrent request = Hm 
can accommodate our design ? | r 


2K 0.5K 
20K 12K 
100K 80K 
500K 300K <= 2 sec 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Evaluate: Microservices Distributed Caching 


Benefits 

Portability; Containers package applications and their 
dependencies into a single unit 

Isolation; Containers provide isolated environments for __-...__-_- 
each microservice 

Scalability; Kubernetes can automatically scale 
containerized microservices up or down on demand 
Observability; platforms provide extensive monitoring a 
logging capabilities. 

Drawbacks 

Complexity; complex to set up and manage. 

Resource overhead; require a significant amount of 
resources to run CPU, memory. 

Performance overhead; can add some overhead to the 

performance 

Dependency on external tools; like Docker and 

Kubernetes Mehmet Ozkaya 627 


Microservices with Containers and Orchestrators 
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Way of Learning — The Course Flow 


Problem 


-  Identify|Clearly e Architecture Approaches e Fill Design Toolbox e Apply Sqftware Tools 
e Patterns e Design Initial version e Application Frameworks 
e Principles & Best Practices e Databases 


e What's wrong with this architecture ? 
e how we can improve this current design ? 
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Problem: Fault tolerance Microservices able to remains == "= h= h=] 
operational for any failures or disruptions 


Problems 

e Business teams able to deploy new features immediately to 
compete the market 

e Due to heavy traffic, microservices got exceptions and broke some 
major use cases that cause lost revenue 


e Architecture should be designed to be resilient 

Solutions 

e Microservices Resilience and Fault Tolerance 

e Microservices Observability with Distributed Logging and 
Distributed Tracing 

e Microservices Health Monitoring 


, e i Client Apps i i Microservices with Containers and Orchestrators H 

e Create big crisis to customer loyalty An Less Shoppin Ee mat 
! A atalo Cart | Discount( ) l J ! 

Considerations ' 1 1 docker docker = T = 
- Deploy new features immediately without affecting the system ! Ke. COOC |: 
general behaviors | Ir BEE |: 

e System should recover from failures and provide ability ofa ! o 
system to withstands. 4 

| FAA ZS Stream en ! 

i ! e rafom Process È, p= eon CX) 
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Microservices Resilience, 
Observability and 
Monitoring 


Microservices Resilience and Fault Tolerance 

Retry, Circuit-Breaker, Bulkhead Pattern 

Microservices Observability with Distributed Logging and Distributed Tracing 
Elastic Stack which includes Elasticsearch + Logstash + Kibana 
Microservices Health Monitoring 
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Architecture Design — Vertical Considerations 


ett Microservices 
Monolithic 


Decomposition 
Communications 
Data Management 

Transaction Management 
Deployment 


Resilience 


Mehmet Ozkaya 631 


Problem: Fault tolerance Microservices able to remains == "= h= h=] 
operational for any failures or disruptions 


Problems 

e Business teams able to deploy new features immediately to 
compete the market 

e Due to heavy traffic, microservices got exceptions and broke some 
major use cases that cause lost revenue 


e Architecture should be designed to be resilient 

Solutions 

e Microservices Resilience and Fault Tolerance 

e Microservices Observability with Distributed Logging and 
Distributed Tracing 

e Microservices Health Monitoring 


, e i Client Apps i i Microservices with Containers and Orchestrators H 

e Create big crisis to customer loyalty An Less Shoppin Ee mat 
! A atalo Cart | Discount( ) l J ! 

Considerations ' 1 1 docker docker = T = 
- Deploy new features immediately without affecting the system ! Ke. COOC |: 
general behaviors | Ir BEE |: 

e System should recover from failures and provide ability ofa ! o 
system to withstands. 4 

| FAA ZS Stream en ! 

i ! e rafom Process È, p= eon CX) 
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What is Microservices Resiliency ? 


= WMicroservice architecture have become the new model for 
building modern cloud-native applications. 


= But it is increasing interactions between microservices have client Apps! 
created a new set of problems. 


Microservices Partial Failure 


D H 
500 

2——— | Shopping 
e——500 Cart [DB 


= Should assume that failures will happen, and dealing with 
unexpected failures, especially in a distributed system. 


= Network or container failures, microservices must have a 
strategy to retry requests again. 


Kemayed IdV 


= App is going to fail at some point and we need to embrace 
failures. 


= Design microservices with failures that need to be prepared for 
the worst case scenario. 


= What happens when the machine where the microservice is 
running fails ? 
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Cascade Failure in Microservices 


= What happens when the machine where the 
microservice is running fails ? 


Microservices Partial Failure 


= Single microservice can fail or might not be available 
to respond for a short time. 


= Since clients and services are separate processes, a 
service might not be able to respond in time for 


client's request. PER T 


= The service might be overloaded and responding 
very slowly to requests or might not be accessible for 
a short time because of network issues. 


> 
H 
@ 
A 
D 
= 
e 
< 


= If Service A calls Service B, which in turn calls Service 
C, what happens when Service B is down ? 


wm em em em em em em em ep em ep eplen em em em em em em em emm em emm emm emm 
ai Y 


= What is your fallback plan in such a scenario ? fe a 


= How do you handle the complexity that comes with 
cloud and microservices ? 
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What is Microservices Resiliency ? 


= WMicroservice should design for resiliency, needs to be 
resilient to failures and must accept partial failures. 


= Design microservices to be resilient for partial failures, ability ictient Apps! Microservices Partial Failure 
I 


) 
) 
to recover from failures and continue to function. i i 
) 

Catalog © : 

E 

eege, 
m—500 y 
2——— | Shopping 
<—s00 cart ` |\0B) ! 
I 

) 

i} 

i] 

) 

i] 

[] 

i} 


= Accepting failures and responding to them without any 
downtime or data loss. 


= Return the application to a fully functioning state after a 
failure. 
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= Assume that failures will happen and design our 
microservices for resiliency. 


= WMicroservices are going to fail at some point, that's why we 
need to learn embracing failures. 


= WMicroservices system is considered to be resilient, if it can 
continue to function effectively despite failures or disruptions. 


= Should be fault tolerant and handle failures gracefully. 
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Microservices Resiliency Patterns 


= To provide unbroken microservice, the architecture must be 
designed correctly. 


= We can apply to provide uninterrupted microservice, with (Client Apps! 
“Resilience Patterns’. 


Microservices Partial Failure 
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= Resilience Patterns can be divided into different categories 
according to the problem area they solve. 


= Ensuring the durability of services in microservice architecture 
is relatively difficult compared to a monolithic architecture. 


Aemaye5 IdV 


= The communication between services is distributed and many 
internal or external network traffic is created for a transaction. 


= Communication need between services and dependence on 
external services increases. 


= The possibility of occurring errors will increase. 


= There are several patterns that can be used to improve the 


resiliency of a microservices system. 
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Microservices Resiliency Patterns - 2 


= Retry Pattern 
Retrying a request if it fails or times out. Retries can be 
implemented at the client or the service level, to handle temporary 
failures ordisruptions. enn ee e ! 


Microservices Resilience 
Retries = 3 


Duration =2 sec gë 

ExceptionAllowed=20 Catalog 

CheckCircuit= 30 sec DB} 
wg. 


| 
i} 
) 
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= Circuit Breaker Pattern 
Introducing a proxy or "circuit breaker" between a client and a 
service. It will open the circuit and prevent further requests from 
being sent to the service. 


= Bulkhead Pattern ! 


Cart 


Partitioning a system into isolated components, or "bulkheads," to 
prevent the failure of one component from affecting the others. 
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SS 500 
© Circuit Open 

cool Return service fail immediately 

Allow 1 call every 30 sec to check state 


= Timeout Pattern 


time, throw an exception instead of waiting too long. 
= Fallback Pattern 
Providing an alternative behavior or response if a request fails or 
times out. Mehmet Ozkaya 637 


Retry Pattern 


= Inter-service communication can be performed by HTTP or 
gRPC and can be managed by developments. 


= When in comes to network, server and such physical 
interruptions may be unavoidable. ‘Client Apps! 


Microservices Retry Pattern 
Retries = 3 


successfully. 


= Microservices communications can fail because of transient 
failures, but this failures happen in a short-time and can fix 
after that time. 


= If one of the services returns HTTP 500 during the transaction, ! Se a ee 
the transaction interrupted and an error may be returned. | caas | 
= But when the user restarts the same transaction, it may work. = 
, 1 l — |<+—500 ; 
= More logical to repeat the request made to the 500 returned | 9 2——> SE 
service, user will be able to perform the transaction ! T been a 
j 2 |420 


= For that cases, we should implement Retry Pattern. 
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Retry Pattern - 2 


= Retry Pattern allows to automatically retry an operation if it fails. 


= Ensure that a service is able to handle failures or temporary 
unavailability of dependent services. 
Client Apps! Microservices Retry Pattern 


Retries = 3 


Duration = 2 sec 
Catalog 


= Common use of the Retry pattern in microservices is to handle 
temporary failures when calling a downstream service. 


= Le shopping cart service that relies on a payment service to 


process payments. = 
. . Se ——500 . 
= Ifthe payment service is temporarily unavailable due to a A —» SE 
S i . D qj (DB, 
network issue, the shopping cart service use the retry pattern to z $ x R 
DÄ 
< <——200 


automatically retry the payment request. 


= Allow the microservice time to fix itself with self-correct, and 
extend the back-off time before retrying the call. 


= The back-off period should be exponentially incremental 
withdrawal to allow sufficient correction time. 
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Drawbacks of Retry Pattern 


= The Retry pattern should be used with caution. 


= |fa service is experiencing persistent failures or is unavailable for an extended period of time, the 
retry pattern result in an excessive number of failed requests. 


=" In these cases, it is necessary to implement additional strategies, circuit breaking or fallback logic 
to prevent the retry pattern from further impacting the system. 


Microservices Partial Failure 


——500 
2———¥ | Shopping 
—— 500 Cart [DB] 


| 
Client Apps! 


Aemaye Idy 
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Circuit Breaker Pattern 


= Method in electronic circuits that is constructed like circuit 
breaker switchgear. 


= Stop the load transfer in case of a failure in system to protect 
the electronic circuit. 


Microservices Circuit Breaker Pattern 
Retries = 3 


Duration = 2 sec KE 
ExceptionAllowed=20 Catalog 
CheckCircuit= 30 sec ty 
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= Protects against failures in external dependencies, useful in 
microservice when failure in one service can have cascading 
effects on other services. 


CG 1— 
= |4—500 
D 
system. S Cart 
& 101—> 


= |f one microservice depends on another microservice and ax, 
second microservice fails, the first microservice might also fail. 


000) 500 
E Circuit Open 

ceo! Return service fail immediately 

Allow 1 call every 30 sec to check state 


= Circuit breaker pattern prevents cascading failures in a 


= If the first microservice is using a Circuit breaker pattern, it 
can prevent further calls to the second microservice and 
continue to function. 
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Book Flights Example 


= WMicroservices that allows users to book flights. 


= This microservice depends on an external service for --===--- NEE 
retrieving flight information. Client Apps! 


= Ifthe external service becomes unavailable, the flight 
booking microservice will also become unavailable. 


= To protect against this type of failure, implement a circuit 
breaker pattern around the call to the external service. 


= If the external service becomes unavailable, the circuit 
breaker will trip, preventing further calls to the external 
service. 


Aemayed IdV 


= This will help to prevent cascading failures in the system 


zm ep ep ep e e EEE e e e e SC "e e e ese eee em wm am o 
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Circuit Breaker Pattern - 2 


= Circuit Breakers pattern monitors the communication 
between the services and follows the errors that occur in 


1 1 | 
the communication. iClient Apps! Microservices Circuit Breaker Pattern 
Retries = 3 


Duration = 2 sec gë 
ExceptionAllowed=20 Catalog 
CheckCircuit= 30 sec Gy 
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I 
—2— | Shopping = 
SEH Cart E | 
I 
1 
) 
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) 
1 
1 
1 
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= When the error in the system exceeds a certain 
threshold value, Circuit Breakers turn on and cut off 
communication, and returning previously determined 
error messages. 


the communication traffic. 


= Ifthe requested service starts to return successful 


l 
U 
I 
U 
U 
| 
) 
I 
I 
U 
I 
= While Circuit Breakers is open, it continues to monitor | 
I 
I 
I 
I 
I 
. l 
results, it becomes closed. ! 

U 

U 

| 


Allow 1 call every 30 sec to check state 
PE a E EEE E E. 
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Circuit Breaker States 


Closed 
The circuit breaker is not open and all requests are 
executed. 


Open 

The Circuit Breaker is open and it prevents the 
application from repeatedly trying to execute an 
operation while an error occurs. 


Half-Open 

The Circuit Breaker executes a few operations to 
identify if an error still occurs. If errors occur, then the 
circuit breaker will be opened, if not it will be closed. 


CLOSED 
Wi 


success 


-= -> 


try 
one request 


mm wm wm = a = g 


H 
HALF-OPEN 
fail V , 
i 


fast failing 


open circuit 


success 


close circuit 


Circuit Breaker State Diagram 
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Circuit Breaker Pattern 


I 
Client Apps 


Return service fail immediately 
Allow 1 call every 30 sec to check state 
gees eae en ee ee 


i i Microservices Circuit Breaker Pattern . 
Retries = 3 l 
i ı | | Duration = 2 sec E i 
ı | | ExceptionAllowed=20 Catalog 
1 | | CheckCircuit= 30 sec DB, 
'/ l 
1/ r > 
A8 t—500 ! 
i —2—| Shopping 
| a +—s00— cart ` |\08) | 
i 10—p i 
d 500 
' Circuit Open s 
l 
i i 
l | 
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Retry + Circuit Breaker Pattern 


= Retry pattern only retry an operation in the expectation calls since it will get succeed. 


= Circuit Breaker pattern is prevent broken communications from repeatedly trying to send request that is 


mostly to fail. 


Some retry logic 
when request 
fails 


| 
l 
| 
4 Trips exception | 
| Fallback scenario 
< | 
Some retry logic | 
when request 
faits 


Exception threshold | 
exceeded and circuit j 
breaker is open 


A 


Fallback scenario 
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https://www.gokhan-gokalp.com/en/resiliency-patterns-in-microservice-architecture/ 


Bulkhead Pattern 


= Bulkhead pattern is used to isolate failures in a distributed 
system. 


= Based on the concept of a "bulkhead" in a ship, structural 
partition that helps to prevent the entire ship from flooding if 
one compartment is damaged. 


= In microservices, isolate individual service instances or 
groups of service instances from each other, to prevent failures 
in one part of the system from affecting the entire system. 


= One location does not affect other services by isolating the 
services. The main purpose is isolated error place and secure 
the rest of services. 


= Naval architecture; ships or submarines are made not as a 
whole, but by shielding from certain areas, if there is happens a 


flood or fire, the relevant compartment is closed and isolated. 


= WMicroservices able to respond to user requests by isolating the 
relevant service so the error. 


bulkhead deck 
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Bulkhead Pattern - 2 


SPSS SSS SSH SSS SSS SSS SSS OHS SHS SST SP TS, 
me 


` App (without bulkhead) 4 


| 


ji 


SPE OSS SSS mmm SSS SSS SDSS SOTO Me, 


https://speakerdeck.com/slok/resilience-patterns-server-edition?slide=33 
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When to use Bulkhead Pattern 


= WMicroservices use Bulkhead Pattern to prevent failures in one 
part of the system from affecting the entire system. 


= Use cases for bulkhead pattern: 


‘i e S bulkhead deck 
= When a service has a high load and there is a risk of resource pr meng 


contention with other service instances. 


= When a service depends on one or more downstream 
services, and there is a risk of cascading failures. 


= |f a downstream service becomes unavailable or experiences a 
performance issue. 


= When a service is required to make frequent calls to a 
downstream service, and there is a risk of overloading the 
downstream service if it becomes unavailable. 


Mehmet Ozkaya 649 


Timeout Pattern 


= Timeout Pattern provides that should not wait for a service 
response for an indefinite amount of time, throw an exception 
instead of waiting too long. 

= Itis used to handle scenarios where a service call takes longer "ent Apps; 

than expected to complete. ‘ 


Microservices Timeout Pattern 


= Setting a maximum time limit for the service call to complete, if" 
the time limit is exceeded, the call is considered to have «timed n 
out.» nu 


= In microservices, It used to prevent service calls from taking `, 
H 
too long to complete. u 
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= Ifthe payment processing service takes longer than expected 
to complete a request, the timeout pattern used to cancel the 
request and return an error to the shopping cart service. 1-------4 
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Fallback Pattern 


= Fallback Pattern provides an alternative behavior or response 
if a request fails or times out. 


s Ifa service is unavailable, the client could use a cached £ CG: JE aes ENEE CSC ! 
version of the data or display a default message to the user. 


= Itis used to provide an alternative course of action when a 
service call fails or takes too long to complete. 


—] 


or times out, and the function provides an alternative 
response. 


Aemayes Il 


= In microservices, the fallback pattern help to improve the 
overall reliability and stability of the system. 


= Ifthe payment processing service is unavailable or takes too ! 
long to complete a request, the fallback pattern could be used 
to provide an alternative response. 


= Le displaying an error message or offering the user the option 
to try again later. Mehmet Ozkaya 651 


Microservices Observability 
with Distributed Logging and Distributed Tracing 


Microservice have a strategy for monitoring and managing the 


complex dependencies on microservices 


Need to implement microservices observability with using 


distributed logging and tracing features. 


Microservices Observability gives us greater operational 


insight. 


Monitor and understand the behavior and performance of a 


system made up of microservices. 


Distributed Logging and Distributed Tracing are two key tools 


that improve observability in microservices. 


Distributed Logging is a practice of collecting, storing, and 
analyzing log data from multiple service instances. 


Behavior of the system over time, identifying patterns and 


trends, and troubleshooting issues. 


a 
Microservices Distributed Logging and Distributed Tracing 
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Microservices Observability 


with Distributed Logging and Distributed Tracing 


= Distributed Tracing is tracking the flow of requests through a 
microservices architecture, to see how the different service 


instances interact with each other. 


= See the performance of the system, identifying bottlenecks, 


and troubleshooting issues. 


a 
Microservices Distributed Logging and Distributed Tracing 
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Real-world Example of Microservices Observability 
with Distributed Logging and Distributed Tracing 


= Implement distributed logging to collect, store, and analyze log data from service instances, include 
information about service calls, errors, performance metrics, and other relevant data. 


= Implement distributed tracing to track the flow of requests through the system. 


= |fa user adds an item to their shopping cart, the trace with information about the request flows from the 
shopping cart service to the payment processing service to the product catalog service. 


| 1 
Client Apps! Microservices Distributed Logging and Distributed Tracing 


I 
I 
[] 
I 
Catalog ; : 
i 
H 


1—»| Shoping 
—500—— 


Correlationld 
Traceld 


Aemaye5 Ly 
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Elastic Stack for Microservices Observability 
with Distributed Logging 


= Elastic Stack is a collection of open-source tools for collecting, 
storing, and analyzing log data and other types of data. 


= Used for microservices observability to provides a flexible and 
e e H H Shaping and visualization E 
scalable platform for monitoring and understanding the behavior. kibana 


= Elasticsearch 
Distributed search and analytics engine that can be used to store 
and index log data and other types of data. 


Analytical capability = 


elasticsearch 


Data parsing - 


= Logstash 
Data collection and transformation tool that used to collect log data 


, . : Data shippin 
from different sources and send it to Elasticsearch. dëm 


= Kibana 
Data visualization and exploration tool that used to create soan ii i a 
dashboards and visualizations based on data. Transform DE Manage 
= Beats = 7 E = E 
Collection of lightweight data shippers that used to collect log data logstash elasticsearch kibana 


and send it to Elasticsearch. 
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Why logging with ElasticSearch and Kibana 
in Microservices ? 


Logging is critical to implement to identify problems in 
distributed architecture. 


Elastic Stack used to collect, store, and analyze log data from 
multiple service instances in a microservices architecture. 


Useful for understanding the behavior of the system over time, Shaping and visualization 


identifying patterns and trends, and troubleshooting issues. 


Elastic Stack might be used to collect log data from each 
service instance. 


Kibana to visualize and analyze the data in order to identify 
patterns or trends. 


SR Search Visualize 
& & 


_ Analyze Manage 


SA e EK 


logstash elasticsearch kibana 


kibana 


Analytical capability = 


elasticsearch 


Data parsing - 


Data shipping 
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Real-world Example with ElasticStack 


Client Apps! Microservices Distributed Logging and Distributed Tracing 


Catalog 
—1—-»| Shoping 
500 Cart 


Correlationld 
Traceld 
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ranstor 


Ordering ke ` E = 


logstash elasticsearch kibana 
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Distributed Tracing with OpenTelemetry using Zipkin 


= Distributed Tracing is used to track the flow of a request as it is 
processed by different microservices in a system. 


= Different microservices are interacting and identify issues or SEET S 
bottlenecks and troubleshooting issues in the system. H e van Me 


= Opentelemetry is an open-source project that provides a set of eo 
APIs for collecting and exporting telemetry data; traces, 


metrics, and logs. e KS 
= Zipkin is a distributed tracing system that collects and stores 


trace data from microservices, provides a web UI for viewing and manner 
analyzing trace data. 


mongodb://db 
2.5 ms 


= To use OpenTelemetry with Zipkin for microservices distributed aero en 
tracing, OpenTelemetry SDK would be integrated. — = 


= Allows to collect trace data as requests flow through the system, —— pepe wm 
and send data to a Zipkin server for storage and visualization. —— ve 
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Real-world Example of 
Distributed Tracing with OpenTelemetry using Zipkin 


= Use OpentTelemetry with Zipkin to collect trace data as requests flow through the system. 
= When a user adds an item to their shopping cart, the trace include information about the request. 


= The trace data collected by the OpenTelemetry SDKs integrated into each service instance, and then sent 
to a Zipkin server for storage and visualization. 


= Use the Zipkin UI to visualize and analyze the trace data, to identify patterns or trends. 


A 


Microservices Distributed Logging and Distributed Tracing 


Catalog ; 


——1—| Shoping 


¿C opentelemetry 


Kemaye5 |IdV 
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Microservices Health Checks: | ae 
Liveness, Readiness and Performance Checks | rd 


= The process of monitoring the health and performance of 
individual microservices in a system. 


= The failure of a single microservice can have cascading ae -ETE 
effects on the rest of the system, important to identify and r 
address issues. 


= What is Health Checks for microservices ? 


= Health Checks for microservices are a way to monitor the 
health and performance of individual microservices in a 
system. 


= Health checks used to determine whether a microservice is 
functioning properly and is able to handle requests. 


= There are 3 types of health checks that can be used for 
microservices. 


D o o o o o o 
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Microservices Health Checks: — Epa 
Liveness, Readiness and Performance Checks OOo r 


"= Liveness Checks 
Determine whether a microservice is still running. If a liveness 


check fails, it may indicate that the microservice has crashed. ——— Sic ties OF 
= Readiness Checks a Be SH 
Determine whether a microservice is ready to handle requesis. If : E 
a readiness check fails, it may indicate that the microservice is ; Ce 
not yet ready to handle traffic. i ani 
= Performance Checks E — | oe 
Monitor the performance of a microservice, such as response x ec 
times or error rates. If the results of a performance check indicate : 
that a microservice is not performing as expected. + e 
. 
+ e 
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Microservices Health Monitoring 


with Kubernetes, Prometheus and Grafana 


Use Liveness and Readiness Probes 
Kubernetes provides liveness and readiness probes that can be used to monitor the health of 
individual microservices. 


Liveness probes check to see if a microservice is still running, and readiness probes check to 
see if a microservice is ready to receive traffic. 


Use Monitoring Tools 

Monitoring tools can be used to monitor the health and performance of microservices that can 
be integrated with Kubernetes to provide alerts or notifications when issues arise. l.e. 
Prometheus, Grafana, Datadog. 


Use Log Analysis Tools 
Analyze log messages generated by your microservices and identify issues or trends. Elastic 
Stack (Elasticsearch, Logstash, Kibana), Fluentd, Splunk. 


Set up Alerts and Notifications 
Setting up alerts and notifications can help to ensure that relevant parties are notified when 
issues arise, allowing them to be addressed quickly. Slack, Teams, Email, SMS. 
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Before Design — What we have in our design toolbox ? - Old 


Architectures Patterns&Principles 


Microservices — 
Architecture 


Event-Driven 
Microservices 
Architecture 


The Database-per- 
Service Pattern, Polygot 
Persistence, Decompose 
services by scalability, 
The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications Patterns 


Microservices Data 
Management Patterns 


Event-Driven Architecture 


Microservices Distributed 
Caching 


Microservices 
Deployments with 
Containers and 
Orchestrators 


Microservices 
Deployment 


Docker and Kubernetes , 


Architecture, Helm Charts 


Kubernetes Patterns; 


Sidecar Patterns, Service 


Mesh Pattern 


DevOps and Cl/CD 
Pipelines 


Deployment Strategies; ° 


Blue-green, Rolling, 
Canary and A/B 
Deployment. 


Infrastructure as code 
(laC) 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Before Design — What we have in our design toolbox ? - New 


Architectures Patterns&Principles 


Microservices — 
Architecture 


Event-Driven 
Microservices 
Architecture 


The Database-per- 
Service Pattern, Polygot 
Persistence, Decompose 
services by scalability, 
The Scale Cube 


Microservices 
Decomposition Pattern 


Microservices 
Communications Patterns 


Microservices Data 
Management Patterns 


Event-Driven Architecture 


Microservices Distributed 
Caching 


Microservices 
Deployments with 
Containers and ° 
Orchestrators 


Microservices 


Resilience , 
Resilience Patterns; 7 
Retry, Circuit-Breaker, 
Bulkhead, Timeout, ° 


Fallback Pattern 


Distributed Logging and ° 
Distributed Tracing 


Elastic Stack; ° 
Elasticsearch + Logstash, 
+ Kibana 


OpenTelemetry using 
Zipkin 

Kubernetes Health 
Monitoring with tools like 
Prometheus and Grafana 


Microservices Resilience, 
Observability and Monitoring 


Non-FR 
High Scalability 
High Availability 


Millions of Concurrent 


User 


Independent 
Deployable 


Technology agnostic 
Data isolation 


Resilience and Fault 
isolation 


FR 


List products 


Filter products as per 
brand and categories 


Put products into the 
shopping cart 


Apply coupon for 
discounts 


Checkout the shopping 
cart and create an order 


List my old orders and 
order items history 
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Microservices Resilience, Distributed Co and Tracing 


1 

i 

I 
Retries = 3 , 
Duration = 2 sec Catalog 8 
ExceptionAllowed=20 : 
CheckCircuit= 30 sec 1 


D 

O —2 

o 500-— 

D Correlationld 
= Traceld 

a) 
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Proble m Learn Design Adapt 


Microservices Resilience, Observability and Monitoring | o | 


Improved fault tolerance 
Help a microservices system continue functioning even in the face of failures or other 
disruptions, making it more fault tolerant. 


Improved uptime and availability 
Implementing patterns circuit breakers and fallback mechanisms, you can ensure that your 
system remains available even when individual components get problems. 


Increased reliability 
When a microservices system is designed to be resilient, it is less likely to experience failures 
or disruptions. 


Enhanced scalability 
Microservices architecture is designed to be scalable, and using resilience patterns can further 
enhance this capability. 


The bulkhead pattern can allow you to scale different components of your system 
independently, without affecting the others. 
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Adapt: Microservices Resilience, Observability 


and Monitoring 


e Express Gateway 
, Amazon AWS API Gateway 


Backend Microservices 
e Java — Spring Boot 


Kema}e5 Idy 


l 
Frontend SPAs Resiliency Pattern ! Client Apps! Microservices Resilience, Distributed Logging and Tracing 
, Angular , Retry i i Retries = 3 i 
, , i | Duration = 2 sec Catalog a 
e Vue e Circuit breaker , . ExceptionAllowed=20 p— : 
. React . Bulkhead CheckCircuit= 30 sec — SA 
API Gateways . Timeout, Fallback ee | @ 
e Kong Gateway - ! —2 
: 
I 
I 
4) 


wm emp eee a = = -= å- mm ml em wm ese ese eee emm emm emm ee = 
A Le 


P 
e Nei — Asp.net Ordering & Ge on 
e JS — NodeJS ! 1 wy eer, Bed, Zant 3 
Distributed Logging Cloud Distributed Distributed Monitoring Cloud Monitoring 
e Elastic Stack Logging Tracing e Kubernetes Health . Azure Application Insights 
, Fluentd e AWS Elastic Cloud « OpenTelemetry Checks e Amazon CloudWatch 
, Splunk , Azure Elastic e Zipkin e Prometheus — Mehmet Ozkaya 667 


e AWS X-Ray Grafana, Datadog 


DEMO: E-commerce 
Implementation of 
Microservices Architecture 


Microservices on .Net platforms which used Asp.Net Web API, Docker, RabbitMQ, 
MassTransit, Groc, Ocelot AP! Gateway, MongoDB, Redis, PostgreSQL, SaqlServer, 
Dapper, Entity Framework Core, CQRS and Clean Architecture implementation. 


Centralized Distributed Logging with Elasticsearch, Kibana and SeriLog, use the 


HealthChecks with Watchdog, Implement Retry and Circuit Breaker patterns with Polly. 
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Implementation of Microservices Architecture 


e Clone Microservices Repository 


OPPO Find X 


e Docker-compose up Newone 
e Follow steps on github 
documentation 
e Run the Project Section Sa Dy E 


IPhone X Samsung 10 Huawei Plus Xiaomi Mi 9 
This phone is his phone is th Th y e phone 


sp e is the This phone is the his phone is the 
company's biggest change company’s biggest change company's biggest change 
ta ite flanchin cmartnhana ta ite flanchin emartnhana ta ite flanchin emartnhane 


https://github.com/aspnetrun/run-aspnetcore-microservices 
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Big Picture of Microservices Architecture 


, Client Apps , 
i i 
i l 
i I 
i WebApp 

l AspnetRunBasics dr 
i l 
| Ferree ares l 
i ' WebSPA l 
WW OU oe. » | 
] i 
l | 
i d 
i @ | 


p e E Wm mm mm åE mm "` Wm mm Im mm mmm | 


e = = = ie pm mm mm mm mm ms ie ms mm rm e H 


Mi i 
Api Gateways / BFF icroservices 


MongoDB 


Ka 

= 
OH GC? 
g i Redis = 
© 5 
2 i Discount.Grpc Se 
o Post 

greSQL 

= i 


Joyebaibby 


S 
i WebStatus SQL Server 
Å- - em 
> a 
Ka 
RPC! ew E 


elasticsearch logstash kibana 
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DEMO: Microservices Architecture Code Review 


pn em = em = = = Ess season gem em gen SS ee ee IC Ga 
i l i i ; 
I Client Apps WW Api Gateways / BFF Riemsanicas ww i 
HERR 
i 7 = I 
H l i i ' MongoDB 
l i 1 ka H 
I i i Basket.API = 
jj f OH = j 
; ars , | | oe i Redis S ) 
spnetRunBasic : Q l Oo 
Ne ` sie 
| EE ee » f i ; 2 Q i PostgreSQL E 1 
í f I e i 
I oe! be 2 DGE l l i Q ; WebStatus SQL Server l 
H ean | 
i ` x z HealthChecks 
I i l 
i 
i S ew E: 
w 
[i O Į I pesLor g Ob P C elasticsearch logstash kibana I 
em ` em en en wen wn wen wen Ä wen wen em em em ee em em em em em em em em em em em em pm em em em em em e 
DEMO: Code review of Microservices Architecture NET Implementation 
e httos://github.com/aspnetrun/run-aspnetcore-microservices 
e httos://github1s.com/aspnetrun/run-asonetcore-microservices 
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Alternative Link - httos://github.com/mehmetozkaya/MicroservicesA\ 
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Serverless Microservices 
Architecture 


AWS Event-driven Serverless Microservices using AWS Lambda, API Gateway, 


EventBridge, SQS, DynamoDB and CDK for laC 
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Introduction - Serverless Microservices 


= Serverless microservices in which the infrastructure is 
managed by a cloud provider and the microservices are 
executed in a serverless computing environment. 


= WMicroservices are automatically scaled to meet the 
demand of the application and developer does not worry 
about provisioning and managing servers. 


= AWS Lambda, Azure Functions and Google Cloud 
Functions are a serverless computing platforms provided 


by AWS, Microsoft Azure and Google Cloud. data state 


Requests to 


= It allows developers to write and deploy microservices endpoints 
that run in response to specific events, suchas an HTTP ` GK 


Resource state 


request or a change to a database. 


TS 


.Net (C#/Powershell) 
Custom Runtime API 
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Example of Serverless Microservices 


= Write the microservice code in a programming language supported by AWS Lambda, such as 
Node.js, Python, or Java. 


= Package the code and any dependencies into a deployable package, such as a ZIP file. 
= Create an AWS Lambda function and upload the package. 

= Configure the function to be triggered by a specific event, such as an HTTP request. 

= Test and debug the function using the AWS Lambda console or command-line tools. 


= Deploy the function to a production environment and monitor its performance using AWS 
CloudWatch. 


EventType = 
RequestResponse 


API Gateway AWS Lambda DynamoDB 
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AWS Serverless services used 


Compute Databases Messaging/Application API Management lac 
Integrations 
AWS Lambda Amazon DynamoDB Amazon EventBridge Amazon API Gateway AWS 
CloudFormation 
GE. me em 
Sy OOO 
AWS CDK 
Amazon Simple Queue Stack 


Service (Amazon SQS) 


Monitoring 


CQ 


Amazon 
CloudWatch 
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AWS Lambda as a Microservice 


= WMicroservice are small business services that can work 
together and can be deployed autonomously / 
independently. 


i I I 
| User Interface `, | Microservices Data Store 
, ' 


=" Lambda is a service that allows you to run your functions 
in the cloud completely serverless and eliminates the 
operational complexity. 


Amazon 
Aurora 


= |tintegrates with the API gateway, allows you to invoke : Amazon | Amazon AWS Lambda ` ? Amazon 
S H e , CloudFront |: | API Gateway ] DynamoDB 
functions with the API calls, and makes your architecture i 
completely serverless. 


= Microservice with AWS Lambda, which removing the | 
architectural overhead of designing for scaling and high ; *™"** | 
availability, NN 7 H 


https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/serverless-microservices.html 


=" Eliminating the operational efforts of operating and 
monitoring the microservice's underlying infrastructure. 
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Serverless E-Commerce Microservice Architecture 


Developed in Serverless environment =: al 


= developing with AWS Lambda 88 Product 
= No Deployment Requirement User zen E 
= and laC by AWS CDK CloudFormation Basket 


AWS API Gateway 
Microservices developed with AWS Lambda 


Databases are no-sqi DynamoDB that can be aS ES 


Stack 
CDK CloudFormation 


key-value pair or document databases 


Message broker system which is Amazon EventBridge 
Eventbus 


Amazon CloudWatch for centralized logging and 
monitoring 


By default automatic scalability and high avaliability 


Product Microservice 


AWS Lambda AWS DynamoDB 


Basket Microservice 


AWS Lambda ` AWS DynamoDB 


AWS Lambda 
es) 


Ordering Microservice 


AWS DynamoDB 


e G 
ET SA "TI EventBridge 
Rules 
AWS SQS 
Queue 
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Ej: 
EventBridge 


Event bus 


Lo 
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Design: Serverless E-Commerce Microservices 


User 


CDK CloudFormation 


AWS Cloud 


Product 


AWS API Gateway 


Basket 


Product Microservice 


AWS Lambda 


AWS Lambda 


AWS Lambda 


AWS DynamoDB 


AWS DynamoDB 


AWS DynamoDB 


Checkout 
Event 


jesign Adapt 


EventBridge 
Rules 
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Thanks 


Thank you so much for being with me on this journey. 


Reviews and feedback is really encourage to me for pushing forward 
to create new courses like this. 
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